Error Handling and Logging for Object-Oriented Perl Application

hackdaddy has asked for the wisdom of the Perl Monks concerning the following question:

I am writing an object-oriented Perl application with 30 to 40 classes.

My cohort and I have been having heated discussions about the implementation and behavior of the error handling and logging of the application.

Essentially we are looking for the best practices to accomplish this in an object-oriented Perl application.

Thus far we have a logging class that is inherited by classes that want to log. The logging class has class data that we initialize immediately on starting the application. However, as we work through the design, it appears that the logging class and error handling can share some of the same work.

Can you point out some best practices for the implementation of error handling and logging.

Thanks, hackdaddy

Comment on Error Handling and Logging for Object-Oriented Perl Application

Replies are listed 'Best First'.
Re: Error Handling and Logging for Object-Oriented Perl Application by dws (Chancellor) on Apr 18, 2002 at 04:21 UTC
Essentially we are looking for the best practices to accomplish [error handling and logging] in an object-oriented Perl application. Logging and error handling are two separate beasts, related only in that you typically want to log errors. I've build logging into OO and non-OO applications, and there's really not much difference (other than having a logging singleton to pass log messages to). What really matters is what you choose to log and how frequently. That'll depend entirely on your application. I typically log all user actions and any errors or warnings, then provide switches to throw to cause additional detail to be logged (such as SQL queries). The "best practice" I can recommend is to hold a discussion session to answer the question "what kind of information are we going to need in logs to diagnose problems?" Throw a couple of realistic candidate problems onto the table, then talk through what info you'd like to see logged, and who needs to do the logging. And alway include timestamps with each log message. I'd be careful about tying error handling and logging together, other than to make a call to the logging object from your error handling object/code.	[reply]
Re: Error Handling and Logging for Object-Oriented Perl Application by tachyon (Chancellor) on Apr 18, 2002 at 04:07 UTC
If you use Apache as an example there are a two logs but only one of them is called `error.log` which hints at the heirarchy. You may want to log a variety of things, only one of which is errors. To my mind `log` is a base class that `error` inherits from/uses and adds the `email_admin() lie_to_user() and die_if_realy_bad()` methods to. You may of course want to add more mundane methods like `roll_back() retry() and recover()` but that is up to you.... Time is a vital element (who changed what at 10:03:42 that broke the widget module) plus whatever else seem relevant. Relevant should be a topic of discussion. It is obviously better to log too much (you can filter) than too little (use ESP?) You can always rotate the logs if they get to big but you can never recover electrons that have been lost. cheers tachyon s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print	[reply]
Re: Error Handling and Logging for Object-Oriented Perl Application by Matts (Deacon) on Apr 18, 2002 at 13:28 UTC
Best practice logging is simply to use Log::Dispatch::Config. It will take care of all your logging needs, and just quite simply be the right way to do logging. Trust me on this one. Best practice error handling is to use exceptions. Otherwise you end up passing return codes back up the stack, and with 30 or 40 classes that's going to get messy. Try using exceptions by throwing objects - good modules to use for this are Exception::Class and Error (though beware of the try/catch syntax offered by the latter - it's tempting but uses closures so can lead to memory leaks if you don't know what you're doing). Also I recommend a $SIG{__DIE__} handler for catching non-object exceptions (i.e. when someone just does "die 'Foo'" in their module), this way all your exceptions can provide useful backtrace information. And yes, I have a talk on this for the upcoming Perl Conference. ;-)	[reply]