Re: RFC: Exception::Handler
One of the things I don't like about traditional try/catch handling is that it doesn't allow for class level programming. You need to allow any subroutine to try/catch exceptions (die). It's also nice to notify any object in the stack that there is an unhandled exception passing through its code. I'm afraid I don't get it - isn't it what the finally functionality in Error.pm (CPAN) does ? try { stuffThatMayThrow(); } finally { releaseResources(); }; This eliminates a lot of explicit try/catches. Well, destructors are of some help too in that issue. (not lighting up a flamewar, just trying to understand the issues - I don't know much about Aspects, but I find exception handling with Error.pm a breeze, even for big projects) -- Tout n'y est pas parfait, mais on y honore certainement les jardiniers Dominique Quatravaux [EMAIL PROTECTED]
Re: RFC: Exception::Handler
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
Re: RFC: Exception::Handler
On Mon, 14 Jan 2002, Rob Nagler wrote: 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. Might be a fun thing to try out using the mysterious PROPOGATE method (try it - implement a PROPOGATE method in your exception class, and watch for when it gets called). -- !-- Matt -- :-Get a smart net/:-
Re: RFC: Exception::Handler
Matt Sergeant writes: I don't like this for the same reason I don't like $SIG{__DIE__} - it promotes action at a distance. In a 1000 line .pm file I *want* to have my exception catching mechanism next to my eval{} block. You need this flexibility, but Perl allows you to do more, for good reasons. One of the things I don't like about traditional try/catch handling is that it doesn't allow for class level programming. You need to allow any subroutine to try/catch exceptions (die). It's also nice to notify any object in the stack that there is an unhandled exception passing through its code. This eliminates a lot of explicit try/catches. This allows reuse without clutter. If you're familiar with Aspects, it's basically the same concept. Rob
Re: RFC: Exception::Handler
On Fri, 11 Jan 2002, Tatsuhiko Miyagawa wrote: use Exception::Handler MyException = \my_handler, AnotherException = \another_handler, __DEFAULT__ = \default_handler; eval { MyException-throw }; # my_handler() eval { AnotherException-throw; };# another_handler() eval { YetAnotherException-throw; }; # another_handler() : hierarchical eval { FooBarException-throw; }; # default_handler() I don't like this for the same reason I don't like $SIG{__DIE__} - it promotes action at a distance. In a 1000 line .pm file I *want* to have my exception catching mechanism next to my eval{} block. -- !-- Matt -- :-Get a smart net/:-