On Feb 15, 2011, at 5:18 PM, Massimo Manghi wrote:
> I thought for a while about the possibility of doing recursive handling of the
> abort_page generated error, but I thought in most cases the abort code passed
> to abort_page could help to cope with what required an interruption and there
> wasn't a compelling need for nested interruptions. Maybe I had it wrong, we'll
> see in the practical usage. Furthermore, coding it the way it is required
> little changes

I completely agree with your approach and I don't think it's necessary to try 
to do anything about recursive abort_page.  It's up to the Rivet developer to 
make sure their before and after scripts, rivet_error proc, etc, either work 
properly or reasonably handle when they don't.

Where Rivet callsTcl_Eval* in mod_rivet.c, if an error is returned, it either 
does special handling in the case of page processing (i.e. 
Rivet_ExecuteAndCheck) such as handling abort_page, invoking the error script, 
etc, or it logs the error in every other case.  I think that's prudent and 
appropriate and really about as much as we should try to do.

Beyond that, it's up to the developer to test and develop reasonable before and 
after scripts, etc.  FlightAware has a pretty sophisticated ErrorScript proc.  
It inserts uncaught tracebacks into a rivet_errors table in the database, along 
with other stuff like the user ID if logged in, the URL, webserver host, etc.  
But of course a lot of things can go wrong with that, like if things are really 
screwed up we might not even have a database connection.  So we have a dead 
simple error proc that wraps the fancy one in a catch and does the minimum if 
that dies.  In fact, here it is:

## NOTE ALSO: If flightaware_error_guts traces back, we exit the child process!
##
proc flightaware_error {} {
    if {[catch flightaware_error_guts catchResult] == 1} {
        catch {::bsd::syslog log error "flightaware_error: TRACEBACK IN 
flightaware_error!!! - $::errorInfo"}
        catch {puts stderr "TRACEBACK in flightaware_error!" - $::errorInfo - 
exiting the child!}
        exit 244
    }
}

It might be a little radical to exit the Apache child if rivet_error traces 
back but our sense (and experience) is that, once it was debugged, a failing 
flightaware_error_guts meant things were screwed up enough that we didn't want 
Rivet trying to use the interpreter anymore.


Reply via email to