-
In the process of learning perl a while back, and after programming in Python for a year, I found the eval block method that perl uses inelegant. I eventually got used to the standard way of doing exceptions in perl, but at the time I was impressed by the following snippet of code from the perlsub manpage:
sub try (&@) { my($try,$catch) = @_; eval { &$try }; if ($@) { local $_ = $@; &$catch; } } sub catch (&) { $_[0] } try { die "phooey"; } catch { /phooey/ and print "unphooey\n"; };
"That's neat!", I thought to myself. So, I decided to play around with it to understand how it worked, and to see if I could improve it. The result was I dreamt up a rather bizarre yet (IMHO) interesting variation on handling exceptions. The "interesting" part is that the exception handler lets you continue within the block that threw the exception after handling it.

Exception.pm:

package Exception; use strict; our ($try, $catch, $prior_catch); BEGIN { use Exporter; our ($VERSION, @ISA, @EXPORT); $VERSION = "0.04.5"; @ISA = qw(Exporter); @EXPORT = qw(&try &catch); *CORE::GLOBAL::die = \¨ # this really should probably be d +one another # way or at least be optional. } sub die { my $catch_sub = $catch; local $catch = $prior_catch; local $_ = shift; chomp; (defined($catch_sub) && $catch_sub ne "" && &$catch_sub) || CO +RE::die $_; } sub catch (&) { } sub try (&@) { local $prior_catch = $catch; { local ($try, $catch) = @_; eval { &$try; } } &die($@) if $@; } return 1;
exceptiondemo.pl:
#!/usr/bin/perl use strict; use Exception; sub throw { my $err = shift; print "throwing $err\n"; die $err; } catch { die "You shouldn't see this.\n"; }; # This would simply be ins +ane try { throw "foo"; try { throw "bar"; throw "baz"; print "You should NOT see this line, baz was fatal to +this block.\n"; } catch { /^bar/ and do { print "$_ caught and trapped\n"; return 1; # one means exception is "trapped". # unlike using eval, the execution c +ontinues # in the block that threw the except +ion }; /^baz/ and do { print "$_ caught, but we won't trap it here\n" +; return 0; # zero means "untrapped". Even thoug +h we # can do some processing here, we'll + propagate # the exception "outward" }; }; throw "quux"; print "The outer try block completed successfully\n"; } catch { /^foo/ and do { print "$_ caught\n"; return 1; }; /^baz/ and do { print "Caught $_ in outer catch, we'll trap it now\n"; return 1; }; /^quux/ and do { print "$_ caught\n"; try { throw "quuux within quux's catch!"; } catch { /^quuux/ and do { print "$_ caught.\n"; return 1; }; }; return 1; }; }; print "\n"; print "Done testing logic!\n";
The code has never been used for anything more than a toy, so be warned that you shouldn't drop this into your latest project and ship it out:P

Replies are listed 'Best First'.
Re: exception handling (the weird way)
by MZSanford (Curate) on Mar 08, 2002 at 09:17 UTC
    Only one suggestion. I would nomally do the following change :
    # old *CORE::GLOBAL::die = \¨ # new $SIG{__DIE__} = \¨
    Not that either is better per-se, but somehow i feel the %SIG method is cleaner... maybe because i shy away from ever writting *CORE:: ... everytime i do, i hurt myself :/
    from the frivolous to the serious
      Unfortunately, that will not work. The $SIG{__DIE__} handler is simply called before die() does it's thing. After the handler exits, die() continues on (unless you call die again within the handler). In order to make the block continue executing when the exception is "handled", I have to make a new version of die smart enough not to actually do it in that case.

      Perhaps there should be a means of controlling whether it acts "globally" or not.

      P.S. I wrote the original post, and posted it "anonymously" by accident. Doh!

      -- O thievish Night, Why should'st thou, but for some felonious end, In thy dark lantern thus close up the stars? --Milton