Mark Stosberg wrote: > Evan A. Zacks wrote: >> 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. > > The patch looks OK to me. If someone really wants to install a global > signal handler /AND/ have http_error() display HTML in this case, they > can locally disable the signal handle.
I wonder if this isn't just a symptom of a larger problem. Dispatch tries force any errors to Do The Right Thing, which for me is to return the proper Apache code so that an ErrorDocument is triggered, without me having to do anything in my app to get an error page. This is probably the Right Thing to do under mod_perl. Under mod_cgi it tries to print a simple HTML page with the error. Maybe this isn't The Right thing and we should be doing something else? CGI::Carp does it's thing via signal handlers, but that's just CGI::Carp. I'd rather not have a specific work-around for CGI::Carp, but a good solution that will also work for CGI::Carp. Thoughts? -- 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]
