> I'm afraid I don't get it - isn't it what the "finally" functionality > in Error.pm (CPAN) does ? > > try { > stuffThatMayThrow(); > } finally { > releaseResources(); > };
One reason for exceptions is to separate error handling code from the normal control flow. This makes the normal control flow easier to read. If releaseResources() is to be called whenever an exception occurs, then it is advantageous to eliminate the extra syntax in the class's methods and just have releaseResources() called whenever an exception occurs and the object is on the stack. Our exception handling class searches down the stack looking for objects which implement handle_die(). It then calls $object->handle_die($die), where $die is the exception instance. This increases the cost and complexity of exception handling, while decreasing the cost and complexity of normal control flow. It also ensures that whenever the object is involved in an exception, handle_die() is called giving it an opportunity to examine the exception and clean up global state if necessary. > > This eliminates a lot of explicit > > try/catches. > > Well, destructors are of some help too in that issue. Not if the object is a class or if the object is still live, e.g. the request context. We don't do a lot of instance creation/destruction in our code. For example, our Task instances are created at start up. They are executed repeatedly. Tasks decide whether to commit/rollback on every execution, independent of the path through the Task class. I'm agree with the need for try/catch. That's often the best way to handle exceptions. There are cases where a global view is need, however. Like Aspects, it ensures that you don't forget or have to put in code where it is absolutely needed. Rob