Structured Data and Knowing versus Guessing

PerlMonks had a new question about the recommendation to use exception objects instead of die "STRING". I posted a link to The Stringceptional Difficulty of Changing Error Messages and started a heated debate over the value of using regular expressions in exception handling.

Consider this.

You have a larger application (because smaller applications rarely need this much discipline, and you're a grown up and can decide for yourself how much safety and reliability your program needs). You have identified several types of exceptional conditions and you want to handle them reliably. Every exceptional condition can possibly include diagnostic information, such as a customer ID or the module name, function/method name, and even line number. You might include the version number of your code and any specific information about the specific host.

In other words, your exceptions have gone beyond "Something happened! Exit the program with a message!" to "Something happened, and here are the details you need to know to diagnose it." The exception may be a system error (Disk full! Network connection gone! Database full of cheese!) or a data error (No authorization for this operation! User record corrupt! Autotune detected!). The exception may be resumable (Lock not acquired!) or fatal (Fox in acquisition talks!).

You'd like to distinguish between those.

If you use exception objects, you can use the class of the exception to distinguish between resumable and fatal exceptions:

my $e;

if ($e = Exception::Class->caught() && $e->does( 'Exception::Resumable' )
{
    ...
}
else
{
    $e->rethrow();
}

... and within the body of the handler you can rely on the presence of attributes in your exception objects:

my $e;

if ($e = Exception::Class->caught() && $e->does( 'Exception::Resumable' )
{
    my $line     = $e->line();
    my $module   = $e->module();
    my $severity = $e->severity();
}

You can go as far as to make these attributes mandatory when creating exception objects, so if your test suite exercises the code paths which create exceptions (as it should), you can rely on correct use of exception data. That is to say, when you catch an exception, you know the interesting data is present.

You can also search your codebase for instances of the strings corresponding to the names of exception classes in both throwing and catching code.

Now consider how to do this with die "STRING". If you're fortunate, you might get line number and filename. Good luck searching for the right text to find exception handlers. Good luck extracting structured information from strings. Good luck verifying the proper formatting of strings in your test suite.

Again, you don't always need this level of control when throwing or catching exceptions—but to decry it as "Java-like" and "unnecessary" and to ignore its advantages in some cases over regular expression matches against text is short sighted.

Update: Robert Sedlacek explains the point succinctly:

Improving your error messages should never be able to break your error handling.