Hi yulivee07,
Don't forget Carp, that's what I'd reach for first (Update: it's a core module). Its pros are that it reports errors as coming from the user's code, not necessarily the module's code, which is advantageous in the case of errors like "incorrect parameter passed". Second, users can enable stack traces, which can make debugging a whole lot easier. I'd only reach for a logger second, and even then I'd make it optional, since not everyone needs or wants a full-fledged logger.
As for the "should I return a false value or throw an error" discussion, I dimly remember there have been several discussions of that question here on PerlMonks, unfortunately my Super Search skills are currently weak, but if I find them I'll update this node. Update: Here we go, a selection:
Update 2: Just to briefly touch on the question of "return a false value vs. throw an error", I would make that decision based on what's truly an error vs. what is something that can occur normally (there is a bit of a gray area there too). For example, since you said you're writing a module for LDAP stuff, I'd say that something like "can't connect to server" should probably be an exception (via Carp), whereas for something like "no search results found", your function can return a false value. For the latter, note that there is a difference between return; and return undef;, in addition to being discussed in some of the above threads, here is another thread on that issue (and more, via search).
Hope this helps,
-- Hauke D
In reply to Re: Best practices for module error-reporting (updated x2)
by haukex
in thread Best practices for module error-reporting
by yulivee07
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |