You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Witek Mozga <mo...@trimen.pl> on 2019/02/11 10:27:48 UTC

nested catch and abort_page

Hello,

Maybe I`m getting something wrong but shouldn`t "abort_page" stopped
executing code completely? I have a simple example where it does not.

Can anybody explain me why external_problem is set and why then the
external abort_page is not executed? Tested using rivet-2.3.5 and 3.1.1

<?
set external_problem [ catch {        
	
	set internal_problem [ catch {      
	    # make some error here to catch it
	    puts"" ; #error
	} internal_zonk ]
	
	if { $internal_problem } {
		puts "$internal_zonk"
		abort_page		
		puts "This should not be put" 
	}

} external_zonk ]

if { $external_problem } {
    puts "$external_zonk"
    abort_page

    puts "Why this is put?"    
}
?>


-- 
Witek Mozga

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org


Re: nested catch and abort_page

Posted by Massimo MANGHI <ma...@unipr.it>.
Hi Witek

good to know you're developing with Rivet. I recommend the reading of 
the manual pages

http://tcl.apache.org/rivet/manual3.1/catch.html
http://tcl.apache.org/rivet/manual3.1/try.html

which explain the whole business about these shadow commands

regards

  -- Massimo


On 2/12/19 2:54 PM, Witek Mozga wrote:
> Hello,
> 
> Thanks for explanations;  ::rivet::catch does the job for me.
> 
>   I`ve been using Rivet since 2012 and I can see that many things has
>   been introduced that are unknown to me. Good to know that Rivet is
>   actively developed.
> 
> Thanks & Regards
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org


Re: nested catch and abort_page

Posted by Witek Mozga <mo...@trimen.pl>.
> 2) AbortScript interrupts the execution by returning a special and 
> reserved error code that signals the call to abort_script. In order 
> prevent a 'catch' or 'try' construct from trapping this error two
> shadow commands were introduced: ::rivet::try ::rivet::catch.


Hello,

Thanks for explanations;  ::rivet::catch does the job for me.

 I`ve been using Rivet since 2012 and I can see that many things has
 been introduced that are unknown to me. Good to know that Rivet is
 actively developed.

Thanks & Regards

-- 
Witek Mozga

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org


Re: nested catch and abort_page

Posted by Massimo Manghi <mx...@apache.org>.
I'm testing your problem with Rivet 2.3.5/2.4.0 but think the same 
discussion could apply to 3.0/3.1

There are two issues with your code:

1) abort_page is meant to have effect only once. That means that the 
command is supposed to interrupt the request processing and hand the 
execution straight to the abort script. That's why any subsequent call 
to abort_script has no effect whatsoever.

2) AbortScript interrupts the execution by returning a special and 
reserved error code that signals the call to abort_script. In order 
prevent a 'catch' or 'try' construct from trapping this error two shadow 
commands were introduced: ::rivet::try ::rivet::catch.

In fact changing your script as

set external_problem [ ::rivet::catch {

        set internal_problem [ catch {
	    # make some error here to catch it
	    puts"" ; #error
	} internal_zonk ]
	
	if { $internal_problem } {
		puts [::rivet::xml $internal_zonk [list pre class bluebox]]
		abort_page
		puts [::rivet::xml "This should not be put" [list pre class redbox]]
	}

} external_zonk ]

if { $external_problem } {
     puts [::rivet::xml ">$external_zonk<" [list pre class bluebox]]
     abort_page

     puts [::rivet::xml "Why this is put?" [list pre class redbox]]
}

prevents the last line from being printed. As a matter of fact the whole 
last block of code is not executed because the first abort_code jumped 
out of the script to seek for any possible AbortScript defined

If you want this block to be executed anyway you should replace 
abort_script with some tailored return call

  return -code error -errorcode <your-error-code>

  -- Massimo



On 2/11/19 11:27 AM, Witek Mozga wrote:
> Hello,
> 
> Maybe I`m getting something wrong but shouldn`t "abort_page" stopped
> executing code completely? I have a simple example where it does not.
> 
> Can anybody explain me why external_problem is set and why then the
> external abort_page is not executed? Tested using rivet-2.3.5 and 3.1.1
> 
> <?
> set external_problem [ catch {
> 	
> 	set internal_problem [ catch {
> 	    # make some error here to catch it
> 	    puts"" ; #error
> 	} internal_zonk ]
> 	
> 	if { $internal_problem } {
> 		puts "$internal_zonk"
> 		abort_page		
> 		puts "This should not be put"
> 	}
> 
> } external_zonk ]
> 
> if { $external_problem } {
>      puts "$external_zonk"
>      abort_page
> 
>      puts "Why this is put?"
> }
> ?>
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org