2010-07-18

Current Limitations In Exception Driven Perl: Exception Base Classes.

I've started re-attempting to do Exception Oriented Perl Programming recently, and quickly discovered a whole raft of things that got in my way.

This is the first of such things.

I was very much appreciative of Exception::Class, it looks Mostly to Do The Right thing, its mostly simple and straight forward, it itself has some apparent limitations with regard to exception driven code, but I'll cover those later.

The biggest annoyance I have at present is there is no apparent de-facto base set of Exception classes to derive everything else from. I was expecting some sort of Exception Hierarchy much like Moose's Type Hierarchy, but none is to be found anywhere, and this stinks.

Is everyone to have their own base hierarchy for everything? The idea of every project having its own FileException class ship with it to me feels like Fail, and this problem I feel will be needed to addressed before more people start taking exception driven Perl seriously.

Additional to this fun, is presently, all the exception classes share the same name-space as everything else in Perl, because they're just Perl packages. I accept this limitation is mostly Perl's fault, but I still dislike it. The 'Type' name-space suffers a similar problem, but its not quite so bad.

The challenge here is having adequate classes to represent accurately all the classes of exception one wishes to provide, but have them still sanely organised, but without people needing to type out 100character incantations just to throw an exception.

Something akin to MooseX::Types which injects subs into the context would be nice-ish, the only problem there is when you do something stupid like create/import an exception with a name identical to a child namespace, ie: 

   package Bar;
   use SomeTypePackage qw( Foo );
   use Bar::Foo; # Hurp durp. Bar::Foo->import() ==> Bar::Foo()->import() 
   Bar::Foo->new(); # moar hurp durp. Bar::Foo()->import()

Its reasonably easy to work around, but discovering you've failed in this way is slightly less than obvious.

Posted by KENTNL at 6:15:00 PM
Labels: , ,

2 comments:

  1. It seems like you want to spend some time with TryCatch. It's got all the functionality you speak of, except the "standard exception library"

    However, I can certainly see the value in having such a thing, especially if your applications exceptions can be 'decorated' with standard exceptions, rather than a strict inheritance hierarchy. (for example, a ConfigLoadError exception with a FileNotFound exception attached to it. In another case it could have attached an InvalidData exception...)

    If I may make a suggestion though - the description "Exception Driven Perl" makes me cringe. I have seen horrible, horrible abuse of exceptions in other languages, and to think that a language should be "exception driven" seems just plain bad. Code should never be written with the expectation that it will be driven by its exceptions. They are, after all, called *exceptions* for a reason! :) IMO, what we need are better and more consistent means of making those exceptions as useful as possible.

    I'm guessing what you really mean is that you want more robust, standard ways of having and using exceptions in Perl - and that in itself is something we can both agree on heartily!
    ReplyDelete
  2. @Hercynium : I agree completely with your arguments =). I'm aware of TryCatch, but without the standard exception library, I feel its applicable scope is largely limited. :(

    I was considering something akin to ( or using ) Moose Roles would be handy, because then you could munge one exception to represent a variety of compatible causes.

    When I say "Exception Driven", I more or less mean "Actually using Actual exception objects to do something practical every now and then", but I couldn't think of a simpler more expressive way to say it that way. I didn't mean to imply that Exceptions were the *core* concept of the development style =)

    Thanks for feedback.
    ReplyDelete

Subscribe to: Post Comments (Atom)