Invoking abort_page triggers ErrorScript

[Karl Lehenbauer <ka...@flightaware.com>]

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?

Re: Invoking abort_page triggers ErrorScript

[Massimo Manghi <ma...@unipr.it>]

 hold on, I've found out a wrong error message in the lines that handle 
 the AbortScript.

             if (strcmp (errorCodeSubString, "ABORTPAGE") == 0)
             {
                 if (conf->rivet_abort_script)
                 {
                     if 
 (Tcl_EvalObjEx(interp,conf->rivet_abort_script,0) == TCL_ERROR)
                     {
                         CONST84 char *errorinfo = Tcl_GetVar( interp, 
 "errorInfo", 0 );
                         TclWeb_PrintError("<b>Rivet ErrorScript 
 failed!</b>",1,globals->req);
                         TclWeb_PrintError( errorinfo, 0, globals->req 
 );
                     }
                 }
                 goto good;
             }

 The message should read "<b>Rivet AbortScript failed!</b>": do you have 
 an abort script
 that fails and the misleading message be displayed? I'll fix it right 
 away anyway

  -- Massimo



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

Re: Invoking abort_page triggers ErrorScript

[Massimo Manghi <ma...@unipr.it>]

 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-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org