Error Checking: Have you tried 'Try/Catch'?

[tadman]

In an experiment that involved abusing Perl quite badly, I discovered the "try/catch" method explored¹ in The Camel Book, which implements a pseudo-C++ style of error checking and recovery. The usage is paraphrased here:

     try {
          die "screaming";
     } catch {
          /screaming/ and print "Stop screaming.\n";
     };

This is implemented using the ability of Perl to have anonymous subs passed as parameters to functions, provided they have a compatible prototype² such as sub try(&$){}.

Implementation details aside, has anyone used this try/catch method in Perl to any significant degree, or is there an alternative methodology that is more dependable? Just curious. Exceptions (i.e. die) in C++ are quite interesting. I am thinking that this might be used, for example, to more reliably trap DBI errors in Web applications.

Or, of course, I might be completely delusional.

---

1. "Programming Perl", Chapter 2 - Prototypes
2. For some reason, you can only have the function as the first operator in your prototype, which works fine for map, grep, and what have you, but is strangely rigid considering the broader scope of Perl.

[mirod]

Just for information, here is the True Perl Way (tm):

eval { die "screaming" }; 
if( $@=~ /screaming/)            
  { print "stop screaming\n"; } 
print "happily going on\n";

$@ is empty ('') if the eval succeeds, otherwise it contains the error message returned by the code.

[brother ab]

Have you tried Error (and its extension Error::Unhandled which is sometimes more reliable)?

These two are excellent OO-modules for error handling with all features you could imagine - try/catch/except/otherwise/finally.

-- brother ab

[BrentDax]

2. For some reason, you can only have the function as the first operator in your prototype, which works fine for map, grep, and what have you, but is strangely rigid considering the broader scope of Perl.

I have a theory on this one. (Brace yourself...)

The only reason Perl can do that on the first argument is because it absolutely knows the first arg is a sub ref. If you had a prototype like foo($&), how is Perl to know what this means? (This is NOT a perfect example, but I think you can get the idea.)
foo $bar{$baz};
Is the {} a chunk of code, or someone trying to get a hash element and getting a scalar and a sub ref stored in that position? Obviously this depends on whether foo is a scalar or hash, but Larry and Friends decided not to write a complicated chunk of code for dealing with this, and I can't blame them. Just remember that the whole {}==sub{}, thing is a convenience only available when they can be absolutely sure of its meaning.

=cut
--Brent Dax


@HPAJ=split("", "rekcaH lreP rentonA tsuJ");
print reverse @HPAJ;  #sucky but who cares?

[tadman]

You certainly have a good point from a parsing perspective, and this is likely where most of the implementation issues arise. Still, this limitation is really not all that different from the way Perl treats $AUTOLOAD type function calls. You have to be careful to adjoin the function name with brackets, because the compiler isn't astute enough to find the function reference, instead assuming there is a bare word in your code, and whining accordingly. Here's how the compiler appears to behave when finding functions to AUTOLOAD:

     Func($x)        -> &Func($x)  OK
     Func ($x)       -> 'Func' ($x)   !?!?

So, presumably, the same thing would apply to the parsing of curly braces, in theory:

     foo $bar{$baz}  -> &foo($bar{$baz})
     foo $bar {$baz} -> &foo($bar,sub {$baz})

I discovered this trying to eliminate the requirement for 'my ($self) = @_' having to be in every function for an OO program by writing a wrapper which did it for you. For whatever reason, you can't operate on a named sub. Oh well.

[PsychoSpunk]

Template Toolkit implements a TRY/CATCH block that intrigues me a little. Especially when you begin to consider that from a dogmatic view, the point of TT2 is to remove the form from the function. Thank God they're pragmatic and realize that the user may not always do this.

I have yet to actually delve into this piece of the toolkit, but I'm also just trying to feel it out right now.

What's this got to do with selling kids for rice in China? I dunno. But I'm thinking that it might be useful for trapping the same errors you're worried about. I am not saying that you should rewrite to use the toolkit (unless it fits your needs and you can), but perhaps to glean some implementation details from it.

ALL HAIL BRAK!!!