Mark Stosberg wrote:
On 2004-08-23, Kinyon, Rob <[EMAIL PROTECTED]> wrote: Thanks for the response. Your counter-points are sound. While I understand your proposal would be backwards compatible, I have concerns that it could promote what I think is poor application design-- sending un-trapped perl death messages to the user.
That depends. I think sending detailed error messages to the user is bad during production but during development I think it oh so handy.
Granted, it would be possible to design an error_mode that behaved better: It could write the error to a log file, and return a generic and friendly error message to the browser.
I'm interested in feedback from other C::A users on the list:
Is this an interesting feature you would use?
I don't know if my earlier feedback wasn't seen or what, but here's some of what I said in a previous post...
Mark Stosberg wrote:
> On 2004-08-19, Kinyon, Rob <[EMAIL PROTECTED]> wrote:
>> Then, within C::A::run(), eval around the call to $rmeth and, if $@ is
>> set, set $body equal to the result of a call to $self->error_mode. If
>> that sets $@, then continue as it happens today.
>
>
Or maybe have a built in error() sub that would be overridden in the application. This way, existing C::A wouldn't have to change and newer apps could benefit from it.
> This solution is a little less flexible, because the only input you give
> to "error_mode" is "$@". You would then have to parse the string to see
> whether you got back a friendly error message (from an intentional
> "die"), or some deadly error from deeper in Perl.
If we do it as an overridden method then it can take any arguments that you want to recieve. Also, as a built in method it could be used as Rob suggested earlier to catch any errors from the eval of the run mode. This would still keep the flexibility that you use now and would also give the ease of doing something like ...
die 'HERE';
inside of a run mode (while debugging, etc) and still being able to handle that error as you see fit (showing it inside of the browser, etc).
In short, I would use it. :)
-- Michael Peters Developer Plus Three, LP
--------------------------------------------------------------------- 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]
