Should a Perl module raise exceptions (die/croak)?

When writing a Perl module, is it a good practice to use croak/die inside the module?

After all, if the caller doesn't use an eval block, the module might cra开发者_运维知识库sh the program calling it.

What is the best practice in these cases?

I generally prefer exceptions if you're indicating an error of some kind. Otherwise you have to spend much more time sprinkling error handling code at different levels of your codebase rather than centralising the error handling in appropriate layers of the system - amongst other reasons.

You may find this old thread on perlmonks a useful read. I'll reproduce my comment there below - since I mostly agree with what I wrote back then :-)

Some reasons I like exceptions:

• Robustness. I can forget to check for an returned error value. I cannot forget to check for an exception.

• Brevity. I prefer:

  $o->foo->bar->fribble->ni
  

  to

  $o->foo or return(ERROR_FOO);
  $o->bar or return(ERROR_BAR);
  $o->fribble or return(ERROR_FRIBBLE);
  $o->ni or return(ERROR_NI);
  

• Clarity. With exception based code the "normal" flow of control is more explicit because it is not obscured by error handling code. I think that the first of the two code examples above shows the intent of the code more directly than the second does.

• Separation of concerns. The error condition and the error handler are different ideas.

  • You may want an error to be handled in different ways depending on the context.

  • You may also not know how the error should be handled at the point it occurs.

  • You may not know how the error should be handled at the time you write the code.

  With the return-error-code style you end up having to either:

  • propogate error conditions to where the decision on how they should be handled can be made.

  • propogating error handlers down to where the errors may occur

  Both options rapidly become messy if there are many levels of code between the error condition and the error handler.

• No confusion between return values and error conditions.

There are probably some more ;-)

At least in early stages of production, I like to have plenty of throw exeptions (die early motto). So I can catch quickly any mistake (and save you a lot of time avoiding thinking in the logic and tracking return codes). Then in each release iteration I can reduce the severity of the throws associating them with a $o->debug status. So when you run your tests, die at everything, but when you run your code for real croak instead into a log and only die when unavoidable fatal conditions happens. In my humble opinion this is more flexible that the returning codes I have been using in the old times.

Also a simple 'die' exception is not very useful sometimes, so it is better to have a throw function that prints all the call stack trace (like Carp->confess()|cluck()).

And a good catching mechanism is also handy. use Try::Tiny or TryCatch.

PD: the perlmonk thread pointed by adrianh is a classic.