Another Feature Perl 5 Needs in 2012

In Features Perl 5 Needs in 2012 chromatic asks the question What’s on your list?  Well, my list is long.  But the thing at the top is structured core exceptions.

While I don’t think Perl 5’s exception throwing syntax is completely solved by Try::Tiny (just as it’s time for Perl 5 to have it’s own MOP it’s time for Perl 5 to have its own exception handling syntax to solve that problem in a well-defined way too) that’s not the biggest stumbling block to having awesome exception handling in Perl 5.  The main problem is that Perl 5 still throwing plain old strings as exceptions.

Often I find myself wanting to catch all IO errors, but not runtime stupid-coding errors (My error code is going to handle  a dumb filename, but it’s totally not going to know what to do if I’ve typoed a method name.)  This is hard because my code has to parse the exception string – essentially throw a bunch of regular expressions at it – until it can hopefully figure out what’s going on.  And, of couse, I say hopefully because the strings can (and should, as improvements are made) change between versions of perl.

The correct solution is for Perl to throw structured exceptions.  Where all IO errors are a subclass of the main IO error and all bad method calls are a subclass of the DispatchError error or somesuch.  Then I only have to check that $@ isa IO Error and the whole problem becomes simple.

Now in theory someone could build a version of Try::Tiny that had all this logic built in – did all this parsing for me – so it would seem like I had structured exceptions for all the inbuilt errors.  And as long as this module was updated for each version of perl this would probably work and maybe just be good enough.  But it’s not the correct solution!  It’s going to be slow (oh so slow) and brittle and…bad and right.  I want (no, I demand!) a good and right solution.  Enough with the band-aids!

So structured core exceptions goes to the top of my list.  Which of course means very little since I’m not a core Perl hacker (nor do I play one on TV) and I’m not going to have time or skills to do it myself.  But if the TPF wants to take some of that money I’m paying for core development every month and pay someone to do it, I’d be a very happy Perl programmer. 

Posted in Uncategorized

Permalink 9 Comments

9 responses to “Another Feature Perl 5 Needs in 2012

  1. dimitar petrov

    +1 for structured exceptions in the core

  2. ilmari

    autodie throws structured exception objects, FWIW.

  3. I’d love to see structured exceptions and have pushed for them in the past and done some preliminary classification of existing exceptions. The problem with paying someone is… who? I hope somebody does put in a grant application, though. I’d love to see it happen.

  4. Yes, this is at the top of my list, too. I’ve been meaning to blog this, but am pleased that now I don’t have to. (Yes, I’m lazy—thanks Mark!).

    I think that a new syntax ought to go along with it, too. My primary problem with Try::Tiny is that it uses code refs rather than blocks. This means that when you return, it just returns to the context that invoked try, rather than the bock the try was called from, which is how eval and do, among others, work. It’s how try should work, too.

    But yeah, structured exceptions are the most important part, no doubt.

    • 2shortplanks

      So, going completely off topic of structured exceptions and onto Try::Tiny block problems, the solution I use for returning from the scope containing the try and catch ‘block’ is to use RETURN which is provided by Error::Return

      use Try::Tiny;
      use Error::Return;
      sub foo {
          # ...
          try {
              # ...
              # return() here doesn't do what you might think it does
              RETURN 'bar';  # this actually returns from foo()
              # ...
          } catch {
              warn "caught error [$_]\n";
          # ...

      Of course, this is a syntax hack, and is something that needs fixing. But until it is fixed.

  5. McA

    The build-in exceptions are one big reason why I looked at Python years ago. IMHO it’s missing dreadfully.

  6. What happened to Err? it sounded cool from your talk at yapc ( ) but it’s got a big fat warning on it on CPAN.

    • 2shortplanks

      Good point. I’ve been using it on my own DarkPAN stuff for ages and its essentially fine. I should re-release without the warning. Watch this space.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: