[cgiapp] RE: Proposal for Error handling runmode

["Kinyon, Rob" <suppressed>]

Mark -

	I think you're right - start simple and let people ask for the
trap=>1 option. Small changes, released often. Gotta remember that. :-)

	Sounds good.

Rob

-----Original Message-----
From: Mark Stosberg [mailto:suppressed 
Sent: Friday, August 27, 2004 10:25 PM
To: suppressed
Subject: Re: Proposal for Error handling runmode

On 2004-08-27, Kinyon, Rob <suppressed> 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/ 
  
CONFIDENTIALITY NOTICE: The information in this electronic transmission and any documents accompanying it may contain confidential information belonging to the sender, which is legally privileged.  The information is intended only for the use of the individual or entities named above.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this transmission in error, please destroy the message in its entirety. 

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed