On 2004-08-27, Kinyon, Rob <[EMAIL PROTECTED]> wrote:
> I apologize for sending the patch in the wrong format. Future patches
> will most certainly be sent the right way. Thanks for the tip!
I wouldn't say it was "wrong", just less preferable. :) If you don't
receive and process many patches, it's harder to know what a good format
to use might be.
> The reasons I thought to eval the call to the error_mode are:
> 1) If the error_mode() was typo'ed, that should be caught and explained
> 2) If the error_mode() failed for reasons other than an explicit failure
> (such as a bad method call, module not found, or the like), that should
> be caught.
Couldn't we just call UNIVERSAL::can() on the string to cover most of
these cases first?
> 3) There is a potential for the error_mode() to die because the actual
> runmode that died left the application in an unexpected state. That's
> why the die() for the error_mode dying also indicates the runmode that
> was supposed to run, but failed.
I agree it's possible that the error handler could have an error, but at
some point you have to relinquish control.
I think the real benefit of adding this method is so that an error
handler can be designed one in a super class, and used widely. I could
even see a "plug-in" that might provide a generically useful one.
Considering this, I think error handler code will generally be "stable"
after it's initially written, and not modified after that. I'm less
concerned about run time errors here, in other words.
> Maybe it would be best if we allowed it as a parameter - do you want to
> trap failures from error_mode() or not? That way, people can choose
> which they want and we can figure out a useful default. Maybe something
> like $app->trap_error_mode( 1|0 ) called during setup()? And, by making
> it a parameter, we can also allow people to say 'During runmode1, I want
> to trap error_mode(), but I don't in runmode2'. Maybe runmode1 has the
> possibility of leaving the app in some unstable state, but runmode2
> doesn't. *shrugs* I'm just free-associating right now. :-)
My inclination is to start simpler: With no error trapping, and no
option to change it.
Later, it could be added as an option if there is clamor for it:
$self->error_mode('personal_failure', trap => 1 );
Mark
--
http://mark.stosberg.com/
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
