What's the best practice in case something goes wrong in Perl code?

Question

Possible Duplicates:
How can I cleanly handle error checking in Perl?
What’s broken about exceptions in Perl?

I saw code which works like this:

do_something($param) || warn "something went wrong\n";

and I also saw code like this:

eval {
  do_something_else($param);
};
if($@) {
  warn "something went wrong\n";
}

Should I use eval/die in all my subroutines? Should I write all my code based on stuff returned from subroutines? Isn't eval'ing the code ( over and over ) gonna slow me down?

Answer 1

The first version is very "perlish" and pretty straightforward to understand. The only drawback of this idiom is that it is readable only for short cases. If error handling needs more logic, use the second version.

Answer 2

Block eval isn't string eval, so no, it's not slow. Using it is definitely recommended.

There are a few annoying subtleties to the way it works though (mostly annoying side-effects of the fact that $@ is a global variable), so consider using Try::Tiny instead of memorizing all of the little tricks that you need to use eval defensively.

Answer 3

do_something($param) || warn "something went wrong\n";

In this case, do_something is expected to return an error code if something goes wrong. Either it can't die or if it does, it is a really unusual situation.

eval {
  do_something_else($param);
};
if($@) {
  warn "something went wrong\n";
}

Here, the assumption is that the only mechanism by which do_something_else communicates something going wrong is by throwing exceptions.

If do_something_else throws exceptions in truly exceptional situations and returns an error value in some others, you should also check its return value.

Using the block form of eval does not cause extra compilation at run time so there are no serious performance drawbacks:

In the second form, the code within the BLOCK is parsed only once--at the same time the code surrounding the eval itself was parsed--and executed within the context of the current Perl program. This form is typically used to trap exceptions more efficiently than the first (see below), while also providing the benefit of checking the code within BLOCK at compile time.

Answer 4

Your two examples do entirely different things. The first checks for a false return value, and takes some action in response. The second checks for an actual death of the called code.

You'll have to decide for yourself which action is appropriate in each case. I would suggest simply returning false in most circumstances. You should only be explicitly dieing if you have encountered errors so severe that you cannot continue (or there is no point in continuing, but even then you could still return false).

Wrapping a block in eval {} is not the same thing as wrapping arbitrary code in eval "". In the former case, the code is still parsed at compile-time, and you do not incur any extra overhead. You will simply catch any death of that code (but you won't have any indication as to what went wrong or how far you got in your code, except for the value that is left for you in $@). In the latter case, the code is treated as a simple string by the Perl interpreter until it is actually evaluated, so there is a definite cost here as the interpreter is invoked (and you lose all compile-time checking of your code).

Incidentally, the way you called eval and checked for the value of $@ is not a recommended form; for an extensive discussion of exception gotchas and techniques in Perl, see this discussion.

Answer 5

Nobody's really addressed the "best practice" part of this yet, so I'll jump in.

Yes, you should definitely throw an exception in your code when something goes wrong, and you should do it as early as possible (so you limit the code that needs to be debugged to work out what's causing it).

Code that does stuff like return undef to signify failure isn't particularly reliable, simply because people will tend to use it without checking for the undef returnvalue - meaning that a variable they assume has something meaningful in it actually may not. This leads to complicated, hard to debug problems, and even unexpected problems cropping up later in previously-working code.

A more solid approach is to write your code so that it dies if something goes wrong, and then only if you need to recover from that failure, wrap the any calls to it in eval{ .. } (or, better, try { .. } catch { .. } from Try::Tiny, as has been mentioned). In most cases, there won't be anything meaningful that the calling code can do to recover, so calling code remains simple in the common case, and you can just assume you'll get a useful value back. If something does go wrong, then you'll get an error message from the actual part of the code that failed, rather than silently getting an undef. If your calling code can do something to recover failures, then it can arrange to catch exceptions and do whatever it needs to.

Something that's worth reading about is Exception classes, which are a structured way to send extra information to calling code, as well as allow it to pick which exceptions it wants to catch and which it can't handle. You probably won't want to use them everywhere in your code, but they're a useful technique when you have something complicated that can fail in equally complicated ways, and you want to arrange for failures to be recoverable.

Answer 6

Modules that warn are very annoying. Either succeed or fail. Don't print something to the terminal and then keep running; my program can't take action based on some message you print. If the program can keep running, only print a message if you have been explicitly told that it's ok. If the program can't keep running, die. That's what it's for.

Always throw an exception when something is wrong. If you can fix the problem, fix it. If you can't fix the problem, don't try; just throw the exception and let the caller deal with it. (And if you can't handle an exception from something you call, don't.)

Basically, the reason many programs are buggy is because they try to fix errors that they can't. A program that dies cleanly at the first sign of a problem is easy to debug and fix. A program that keeps running when it's confused just corrupts data and annoys everyone. So don't do that. Die as soon as possible.