------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Programs performing database modifications do use another technique though. There I will do things like:

    eval {
         start transaction or die;
         ...
         prepare or die;
         ...
         execute or die;
         ...
         fetch or die;
         ...
     };
     if ($@) {
         rollback;
         die $@;
     }
     else {
         commit;
     }
[download]

If something goes, I die as usual, but this die will be caught, the transaction will be rolled back, and we cascade the die upwards (where it's most likely not caught again).

Abigail

Best Practices for Exception Handling is another node that covers this topic.

This topic has been covered a few times recently. Relevant links can be found here, here, and here. (SuperSearch terms "Error Handling", though Im sure Exception would turn up a decent number of hits too.

In my own code, I attempt to allow as much flexibility as possible in terms of how to handle errors. Though it is also directly related to what the code is supposed to do, and in what type of environment its run in.

use perl;

I used Java before I started using Perl heavily. Whatever else you might say about the language, I must say that the exception handling is great. In Perl, Error.pm replicates much of Java's exception handling (and adds a few things of its own, but I've never used those parts so I can't comment on them).

Back when I was doing Java, I realized that much of the time the exception classes are internally identical. You only need to seperate them from other exceptions for the benifit of the application.

For instance, say you are using DBI, and you want to throw exceptions if it fails to connect, if a prepare() fails, or if an execute() fails. In one module I'm working on right now, I write three seperate exceptions for this, in the following inheirtance tree:

• Error::Simple (already done for me)
• My::DBException
• My::DBPrepareException
• My::DBExecuteException

This is really easy to implement in Perl. At the bottom of my module, I declare all my exceptions like this:

package My::DBException;
use base 'Error::Simple';

package My::DBPrepareException;
use base 'My::DBException';

package My::DBExecuteException;
use base 'My::DBException';
[download]

All the hard work was already done in Error::Simple. The application knows what went wrong because it has (should have) seperate catch . . . with { } blocks for each exception type.

Note that the equivilent in Java requries having a seperate file for your exception (assuming it's used outside your specific class), inheirting from java.lang.Exception, and declaring your own constructor. This will take more than two-lines per exception. (Apoligies if any of the previous wasn't quite right--I've been away from Java for a while).

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated