Fans of exceptions point out that they have lots of advantages.

The critics of exception handling point out that exceptions have many disadvantages.

Perl's exception handling mechanism is somewhat different than that in most languages. People with experience with exception handling in other languages sometimes look down on Perl's approach because it's different.

Using die to throw exceptions, Perl makes the simple exit on error strategy compatible with exceptions. If you don't try to catch an exception with an eval block, the die exits the program.

To support the use of die to display a message and exit, it can use a simple string instead of some special exception object. Many people use regular expressions to look at the thrown string to determine the type of exception. Since die takes

Probably the most common approach to error handling is error returns. Each function defines what it returns in the case of an error and each calling function tests and handles any errors.

Since the error handling is explicit at each call and return, tracing the control flow in the case of errors should be mostly straight-forward. Moreover, if the error is non-fatal, you can just ignore the return value and continue. If any error condition is not handled, the program is not aborted early, unlike exception.

Despite it's ease of use, the error return approach does have disadvantages. The most obvious problem comes from the explicit nature of the error recovery. A program that does a thorough job of recovering from errors can be almost completely swamped in error recovery code.

The less obvious, but more dangerous, problem is the fact that errors can easily be accidentally missed. There is no way to tell the difference between errors you meant to ignore and ones you accidentally ignored.

One complaint that many people make about exceptions is that you have to be very careful because you never know what can throw an exception.

For several years, people have tried different strategies for writing exception-safe code. Most of the approaches that people developed were somewhat ad-hoc, until David Abrahams described the levels of exception safety.

These levels do not tell you how to deal with exceptions, they just provide a way to reason about them.

The first level is not usually on the list, but it is a case you need to consider.

The Basic guarantee covers two issues, no resource leaks and all invariants remain. No exception should leave the code in an unstable or illegal state.

The strong guarantee means that the action either completes successfully or the state of the program is the same as if the code had never executed. This is sometimes called a transactional or atomic guarantee.

The strongest guarantee is the no-throw guarantee which promises that no exceptions are thrown and the code completes successfully.

Without some actual code, it's quite hard to see the trade-offs you need to consider when using exceptions. Most importantly, the difference between exceptions and error returns are much smaller for a small piece of code.

In a 20-line program, it really doesn't matter how you deal with errors. As the code gets larger and more complex, exceptions help to deal with the complexity of error handling.

One problem with trying to demonstrate the usefulness of exceptions is that it becomes more apparent in larger programs. This is a lot like demonstrating objects. Object oriented code and exceptions both seem like mostly overhead in a 20 line program.

Unfortunately, we're not going to want to build a 200K line system two different ways to see the difference. The example that follows is the minimum I could come up with that would begin to show the advantages of exceptions. I hope you can imagine how these differences would expand as a program increases in size.

This is a pointer to some code that has been written without exceptions. It's not real code, but it follows patterns you may have seen.

Here's the same code with all of the potential errors covered.

Here's the same code re-written with exceptions.

The autodie module turns functions that use error returns into functions that use exceptions. Once you get used to using exceptions, this can be extremely handy.

Let's revisit our code sample with autodie enabled.

From the examples, we can see some of the trade-offs that are involved in using exceptions. We can see that progation of errors happens pretty much automatically, which can reduce the lines of code in intermediate functions.

Depending on the code, it is possible to get better coverage because the low-level code can always throw exceptions, knowing that higher-level code will do the right thing. This means that you are less likely to miss a critical mistake because you didn't check for it.

However, the error paths are harder to see, because they may happen mostly implicitly.

When exception objects are used rather than strings, there is an ongoing debate about whether the exceptions should be in one large hierarchy or multiple smaller hierarchies.

The main argument for the one-big hierachy is the catch everything case. Where you want to be able to catch all exceptions with a single base class.

Like most approaches that attempt to stuff everything into one large hierachical structure, this tends to fall down when you end up forcing very different kinds of exceptions into a parent-child relationship.

There are various modules out there that add syntactic sugar to make Perl exception handling look more like other languages. Each has its own trade-offs.

There are also a number of modules that simplify the creation of exception object.

Like any new technique, people often go overboard when they actually get it. Here are a few Dos and Don'ts to keep in mind when using exceptions (in any language).

Exceptions are meant to be used for exceptional or error conditions. They should not be triggered in the normal functioning of the code. You don't need to avoid exceptions, but use them as a tool for the purpose they were designed.

Almost every new user of exceptions comes up with the idea of catching the all exceptions in each function (usually to add a little stack info) and rethrow the exception. This results in a large amount of useless monkey-motion that doesn't actually help matters much.

Catching an exception and ignoring it should be a relatively rare circumstance. By doing that, you are ignoring a potential problem in the code and hiding that from higher-level routines that might actually be able to handle it.

Catch-all handlers are also easy to misuse. Except at the outer-most level of your code (where it serves to catch anything that may have been missed elsewhere). The best use of the catch-all handler for Perl is to propagate any exceptions you didn't handle to higher levels.

If a method answers a simple question with a boolean, don't replace it with an exception in the false case.

If the code calls for an if or switch-type construct, use them rather than overload exceptions for that purpose.

Exceptions can do a very good job of consolidating error handling and recovery. Using them for their intended purpose can make your code more maintainable.

Often the point where you can detect a problem is where you have the least context for dealing with the problem. Don't try to recover from errors low in the code. Throw an exception and let someone else react appropriately for this circumstance.

There's no since in catching an exception, if you can't do anything about it. Allow the exception to propagate to a level with the appropriate context to recover from it.

Sometimes you can't completely deal with an exception, but you can perform some cleanup that would be inconvenient at a higher level. In this case, it is perfectly reasonable to do some recovery and then rethrow the exception for another level to finish the recovery.

No matter how careful you have been, eventually an exception is thrown for which you have no recovery code. It may be caused by maintenance changes changes to a library, or just something you missed. A catch everything case at the highest level of the code prevents this from being a disaster.

In many cases, it is a good idea to catch exceptions at the boundaries of (third-party) modules and convert them into exceptions that your code is able to deal with. This is especially important if the exceptions from the module are very low-level. Logging the exception and converting it into a more generic exception may simplify later code.

By using lexical variables and class DESTROY methods, as appropriate, Perl cleans up resources for you automatically in the presence of exceptions.