Hello folks,
Has anyone else had problems using CGI::Carp's 'fatalsToBrowser'
along with CGI::Application::Dispatch?
Dispatch wraps the CGI::Application run in an eval. When an
exception is caught, the http_error() method is called, which
generates HTML output for an error page (and redirects the user
if necessary).
The problem is, when fatalsToBrowser is used, http_error() hides
the error from the end user. It still logs the error to STDERR,
but the error does not appear in the HTML output.
Attached is a patch to address this problem. I have only tested
it running as a CGI, however. Does anyone know if this is a
reasonable approach to allowing fatalsToBrowser (or another
custom die handler) to pass through?
The idea is that if a custom handler is installed, the
http_error() method should not generate any output, but should
rethrow the exception.
Thanks,
-E
diff -Naur CGI-Application-Dispatch-2.03.orig/lib/CGI/Application/Dispatch.pm
CGI-Application-Dispatch-2.03/lib/CGI/Application/Dispatch.pm
--- CGI-Application-Dispatch-2.03.orig/lib/CGI/Application/Dispatch.pm
2006-09-29 22:07:00.000000000 -0400
+++ CGI-Application-Dispatch-2.03/lib/CGI/Application/Dispatch.pm
2006-10-19 23:13:00.320657968 -0400
@@ -403,6 +403,9 @@
sub http_error {
my ($self, $e, $url) = @_;
+ # allow fatalsToBrowser, for example, to pass through
+ die $e->error if $SIG{__DIE__};
+
warn "[Dispatch] ERROR: '" . $e->error
. ( $ENV{REQUEST_URI} ? "' for request '$ENV{REQUEST_URI}'" : "' ") .
"\n";
my $redirect;
---------------------------------------------------------------------
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]