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.