I agree it's a little self-defeating to eval the error run mode. What
would you do with the caught exception other than die with $@ anyways?
You certainly wouldn't try to run the error mode again.
-Stephen
Mark Stosberg wrote:
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
---------------------------------------------------------------------
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]
