What are the best practices for error handling in Perl?

Question

I'm learning Perl, and in a lot of the examples I see errors are handled like this

open FILE, "file.txt" or die $!;

Is die in the middle of a script really the best way to deal with an error?

Solution 1

Whether die is appropriate in the middle of the script really depends on what you're doing. If it's only tens of lines, then it's fine. A small tool with a couple hundred lines, then consider confess (see below). If it's a large object-oriented system with lots of classes and interconnected code, then maybe an exception object would be better.

confess in the Carp package:
Often the bug that led to the die isn't on the line that die reports. Replacing die with confess (see Carp package) will give the stack trace (how we got to this line) which greatly aids in debugging.

For handling exceptions from Perl builtins, I like to use autodie. It catches failures from open and other system calls and will throw exceptions for you, without having to do the or die bit. These exceptions can be caught with a eval { }, or better yet, by using Try::Tiny.

Solution 2

Since I use Log::Log4perl almost everywhere, I use $logger->logdie instead of die. And if you want to have more control over your exceptions, consider Exception::Class.

It is better to catch your exceptions with Try::Tiny (see its documentation why).

Solution 3

Unless you've got a more specific idea, then yes you want to die when unexpected things happen.

• Dying at the failure to open a file and giving the file name is better than the system telling you it can't read from or write to an anonymous undefined.

• If you're talking about a "script", in general you're talking about a pretty simple piece of code. Not layers that need coordination (not usually). In a Perl Module, there is an attendant idea is that you don't own the execution environment, so either the main software cares and it catches things in an eval, OR it doesn't really care and dying would be fine. However, one you should try at a little more robustness as a module and just pass back undefs or something.

• You can catch whatever dies (or croaks) in an eval block. And you can do your more specific handling there.

• But if you want to inspect $! then write that code, and you'll have a more specific resolution.

• Take a look at the near-universal standard of using strict. That's code that dies on questionable syntax, rather than letting you continue along.

So I think the general idea is: yes, DIE unless you have a better idea of how things should be handled. If you put enough foresight into it, you can be forgiven for the one or two times you don't die, because you know you don't need to.

Solution 4

The more modern approach is to use the Carp standard library.

use Carp;
my $fh;
open $fh, '<', "file.txt" or confess($!);

The main advantage is it gives a stack trace on death.

Solution 5

I use die but I wrap it in eval blocks for control over the error handling:

my $status = eval
{
    # Some code...
};

If the 'eval' fails:

1. $status will be undefined.
2. $@ will be set to whatever error message was produced (or the contents of a die)

If the 'eval' succeeds:

1. $status will be the last returned value of the block.
2. $@ will be set to ''.

View more solutions