Actually it's not supposed to trigger an ErrorScript....details are
simple: abort_page sets "RIVET" as error code and "ABORTPAGE" as error
info,
then it returns TCL_ERROR.
Rivet_ExecuteAndCheck traps the error and checks for the error
code and error info, in case rivet_abort_script is run and
rivet_error_script
is skipped altogether (the code uses an imperative 'goto ...' statement
to jump
over it).
Reviewing the code I've just noticed that just before
rivet_error_script
is run an 'errorOutput' variable is created in the global scope with
the script that caused the error.
Can you see this variable in rivet_error_script? I'm just wondering if
one of the C functions that handle the configuration have messed up
with
the rivet_abort_script and the rivet_error_script object pointers...
if this is true then the variable shouldn't have been set when your
ErrorScript
runs...(the variable is probably persistent across requests, so you
should
unset it beforehand in your script). I'll check it out.
-- Massimo
On Mon, 9 May 2011 21:23:06 +0000, Karl Lehenbauer wrote:
Invoking abort_page seems to cause the ErrorScript to run. I don't
think it used to work this way because we did not consider abort_page
to actually be an error -- we used the error / catch mechanism to
break out of the call stack but we prevented the error script from
running if abort page was invoked.
I think I can fix this for FlightAware by using that –aborting
switch to see if abort_page is running in the error script, but it
seems a bit off to me — abort_page is not, in my opinion, an error
and should not, therefore, trigger the running of the ErrorScript.
Does this seem correct or have I someone misinterpreted what I'm
seeing?
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
