I apologize for sending the patch in the wrong format. Future patches will most certainly be sent the right way. Thanks for the tip!
Thanks for improving the documentation. That's always been my weakest suit. I'll look at what you did and see how I can improve the docs for my own modules. 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. 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. My thoughts on the usage of error_mode were that it would be similar to Window's SafeMode - something that is nearly always guaranteed to return something useful. I didn't think that anyone would _want_ to die from within the error_mode. I figured that people who don't/can't use Apache's ErrorDocument would want to trap run-time failures and provide a useful document to the user while potentially logging/paging out so that the administrator would be notified. 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. :-) The -----Original Message----- From: Mark Stosberg [mailto:[EMAIL PROTECTED] Sent: Thursday, August 26, 2004 8:34 PM To: [EMAIL PROTECTED] Subject: Re: Proposal for Error handling runmode On 2004-08-26, Kinyon, Rob <[EMAIL PROTECTED]> wrote: > ------_=_NextPart_001_01C48B6F.A54FA8DE > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > I've attached a tar.gz of all the files I added and/or changed. I'm not > sure of what format things are supposed to be in, so I just pulled all > the new/modded files together in one directory and tar/gz'ed them up. > > Changed: > lib/CGI/Application.pm > MANIFEST > Changes > New: > t/10errormode.t > test/TestApp11.pm > test/TestApp12.pm > > I've marked this version as 3.23 in Application.pm, if that's ok. Rob, Here's some feedback on this. First a point of administrivia: I find the easiest patch submissions to work with are in the "unified diff" format. In this case, you could generate one easily by using copies of the altered and unaltered directory tries: diff -r --unified unaltered_dir altered_dir >my_patch.txt Below is my own patch to your work to change a couple of things: - I took out setting the default for error_mode(), since it's documented not to have one. - I updated the documentation to reflect the fact that error_mode will be treated exactly like a normal run mode. Like other run modes, you are welcome to explicitly die and exit early if you want to. I also have a general discussion point about the logic. Should we really "eval" the error_mode(), and trap it's death? I thought some of the point of it was allowing the user to "die in their own special way". If we eval it, the options are limited. What do others think? Mark -- http://mark.stosberg.com/ --- error_patch/Application.pm Thu Aug 26 08:15:40 2004 +++ error_patch_modified/lib/CGI/Application.pm Thu Aug 26 19:17:53 2004 @@ -31,7 +31,6 @@ $self->header_type('header'); $self->mode_param('rm'); $self->start_mode('start'); - $self->error_mode('my_error_handler'); # Process optional new() parameters my $rprops; @@ -985,8 +984,8 @@ croak(). If the runmode dies for whatever reason, run() will see if you have set a -value for error_mode(). If you have, run() will call that method and the -data returned is print()'ed to STDOUT and to the browser. +value for error_mode(). If you have, run() will call that method, the same +way a run mode is normally invoked. =back @@ -1019,7 +1018,7 @@ my $self = shift; $self->tmpl_path('/path/to/my/templates/'); $self->start_mode('putform'); - $self->error_mode('my_error_handler'); + $self->error_mode('my_error_rm'); $self->run_modes({ 'putform' => 'my_putform_func', 'postdata' => 'my_data_func' @@ -1556,12 +1555,10 @@ =item error_mode() - $webapp->error_mode('my_error_handler'); - -The error_mode contains the name of a method. It may or may not be a runmode. -There is no default error_mode. The method here will be used if the runmode -that was run fails with a runtime error. + $webapp->error_mode('my_error_rm'); +The error_mode contains the name of a runmode to call in the event that +the run mode call fails C<eval>. There is no default. =item tmpl_path() 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/[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]
