|There's more than one way to do things|
Best practices for module error-reportingby yulivee07 (Sexton)
|on Feb 02, 2017 at 16:37 UTC||Need Help??|
yulivee07 has asked for the wisdom of the Perl Monks concerning the following question:
Hello fellow Perlmonks,
today I am asking for your wisdom in regards to best practices for error reporting in modules. I still would consider myself a novice, so this question may sound foolish to some.
So consider I want to write some kind of Module, currently I am working on one that internally deals with LDAP. The program using the module wants to know, if in a method call to the module something went wrong, e.g. the LDAP-connection timed out or something like this. There I somehow need to report errors happening to my module.
I see multiple ways of tackeling this and I am not content with either of them:
Option 1: report it with Log4Perl
All my programs write logs with Log4Perl anyway. So when my Module encounters an error, I report the Error-Message with Log4Perl and return 1 indicating an error.
Pro: Easy to do, Error easily found in log, not much clutter in my code
Cons: This is not very portable. Someone not using Log4Perl would not be able to use my module.
Option 2: internal error reporting in a moose errors accessor
I tend to write OO-Modules with Moose or Mouse. The module gets an accessor called "errors" like this:
Every public method first calls
$self->clear_errors();, then executes its functionality. Everytime an error occurs I can perform a
$self->set_errors($self->get_errors . $error_message);and stash my errors this way. In the program using the module I can perform a
$module->get_errorsto retrieve the error-messages and a
$module->has_errorsto see if something went wrong.
Pro: Independent from Log4Perl!
Cons: Every Module of mine now has an errors accessor and some helperfunctions to add to this accessor, violating the DRY-principle. Also, not applicable if a method in the module itself, calls another function, as this would erase the errors-accessor. Obviously, doesn't work that great with non-OO modules
Option 3: Return an Error-Code
If everything goes right in a function, return 0. If something fails, return 1 or any higher number.
Pro: No hassle with overwriting error-accessors. I tend to use this for internal module-methods in mix with Option 2.
Cons: A lot! No proper error-message of what went wrong. If the method does return something (e.g. an LDAP-Object) this breaks and burns gloriously.
Currently I tend to use a mix of all these options and I do not like it. Option 2 makes me write a lot of similar code again and again, Option 1 makes me dependend on Log4Perl and Option 3 just doesn't work if the method returns something useful.
CPAN-Authors and Error-Catching-Perfectionists! How do you solve these problems? Proper error-catching is a very important duty in my coding environment as there services I have to work with tend to break a lot or are just not reliable and run a lot into timeouts.
I would love to hear some best practices and further options for dealing with this!