Agreed, though I wish CGI::App would provide a means of catching that and displaying it to the browser rather then throwing up a 500 error and forcing a tail through the server error log.
For errors that occur in the run_mode itself, CGI::App has much improved recently by allowing an error_mode that
can handle the exception.
Unfortunately, this does not cover exceptions before or after the run_mode, such as in one of the hooks or callbacks.
Maybe it could be modified to somehow use error_mode here as well.
If you can provide some code that uses a cleaner error handling mechanism we could look at incorporating it.
Ideally though, I would love to see CGI::App implement a scheme like this by using Class:ErrorHandler as its base (which gives all objects from subclasses the error and errstr methods) and make sure all methods return at least a null string unless something has gone wrong.
Just like HTML templating, exception handling is a topic were everyone has his favourite methods and modules, so it is very unlikely that
we can agree on something more elaborate than the plain die().
Again, CGI::App has greatly improved recently, in that it no longer stringifies the exceptions that your code dies() with, so that if you want,
you can throw hashrefs or Class::Exceptions.
In earlier versions, CGI::App would flatten them to strings, but now it just passes them through, and you can handle them somewhere else ( for example in the error_mode, or your instance script, or a custom run() method that wraps around the original one)
Thilo
--------------------------------------------------------------------- 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]
