views:

169

answers:

2

Thanks to everyone in advance.

I've been doing some research on error handling and I don't feel like I'm getting a solid understanding of what I should do.

Preamble: My code is living in Apache and executed in the browser, my goals don't include command line execution.

I'd like to have the behavior of CGI::Carp (fatalsToBrowser) with the ability to capture the output and be able to throw it in my own templated page, email it etc... I did notice that fatalsToBrowser doesn't work with mod_perl. Does anyone know why? How is Apache/mod_perl getting in the way?


First Goal: I'd like to put something together that works if the code is being executed with mod_perl or mod_cgi.

Second Goal: I'd like to have a high-level method(s) that catches all the errors similar to .NET's Application_Error (in global.asax) and PHP's set_exception_handler() and set_error_handler() methods. These allow you to take control when an error is raised, without wrapping code in messy/gross try-catch statements.


Things I've read/reviewed:

1.) OO Exception Handling in Perl, but wasn't what I was looking for. Most of the stuff I want to catch is die()ing. The next link also says that this article is out of date and deprecated.

2.) Perl: $SIG{__DIE__}, eval { } and stack trace, but I didn't get much from this related to my goals.

3.) Practical Mode Perl (O'Reilly), Chapter 21 "Error Handling and Debugging". Thankfully all my perl code uses strict and warnings are enabled, and most important things mentioned in Chapter 6 "Coding with mod_perl in Mind" are already done.

4.) I've dug through the tables of contents in "Learning Perl", "Perl Cookbook", "Programming Perl" and "Higher Order Perl" and didn't see anything that stuck out at me. If you think I missed something there please let me know. :)


I don't remember where (maybe in "Practical mod_perl", but I've read that you should not mess with $SIG{__DIE__}.

+1  A: 
Sinan Ünür
I allow the programmer to choose if they want the stackstrace shown in the error message... obviously in the production envirnment we would turn off the stack trace being shown. However I'd still like to have access to it so I can show the user a friendly message and email the administrator the real stacktrace or log it to the db etc... Please see my second goal in my OP, I don't want everything wrapped in a try/catch... I need a high level error catcher that can take control from their with thei appropriate information.
rakhavan
Does this look messy/gross to you?
innaM
Yes/No... I think @Weegee gave me what I was looking for. I need something not connected to the script(s) for global error trapping in my applications. I'm gonna see if that works before choosing an answer. Again thanks for your replies, much appreciated.
rakhavan
+1  A: 

Have you read the mod_perl website's bit on Alternative Exception Handling Techniques? It discusses about how you can catch uncaught exceptions though the use of overriding the global die() function instead of using $SIG{__DIE__}. A much cleaner method but not perfect.

Weegee
Thanks a TON! That was a great read.
rakhavan
I'm glad I could help.
Weegee