Recently I was looking the module Error and saw a syntax that I never have used. First when we look the interface of the module we think that it uses a filter to enable the try {...} catch foo {} syntax, but not, it just declare the subs try and catch with a prototype that indicates that it will receive a code and other stuffs.

So take a look in this code:

sub try (&;@_) { print "try>> @_\n" ; } sub CLASS::catch { print "catch>> @_\n" ; return( 'catch' , @_ ) ; } sub with (&;$) { print "with>> @_\n" ; return( 'with' , @_ ) ; }
Now that we have declared our "new syntax", we can use in this way:
try { print "test\n" ; } catch CLASS with { print "alert\n" ; } ;
And the output is:
with>> CODE(0x1a72f20) catch>> CLASS with CODE(0x1a72f20) try>> CODE(0x1a72c5c) catch CLASS with CODE(0x1a72f20)
What I'm wondering now is that this way to do things is documented, since I never saw this kind of code in other modules or at perldoc.

Ps: I think that the module Error should be a standart module. First because it really implement a good way to make/handle exceptions and it's pure Perl and standalone.

Graciliano M. P.
"Creativity is the expression of liberty".

Replies are listed 'Best First'.
Re: Prototype "foo {...} bar {...}" is documented?
by diotalevi (Canon) on Nov 22, 2004 at 00:12 UTC
    Any discussion on this should note that this syntax is noted in perlsub and that code relying on this has an increased likelyhood to leak memory. It isn't a particularly good perl idiom but mostly because of the various implementation considerations that are particularly noxious.
      Yes, is documented with this example:
      sub try (&@) { my($try,$catch) = @_; eval { &$try }; if ($@) { local $_ = $@; &$catch; } } sub catch (&) { $_[0] } try { die "phooey"; } catch { /phooey/ and print "unphooey\n"; };
      Thanks I missed that.

      Graciliano M. P.
      "Creativity is the expression of liberty".

      ... that code relying on this has an increased likelyhood to leak memory.

      Any information on how the memory leakage occurs, and ways to avoid it, would be appreciated.

      Regards,

      PN5

Re: Prototype "foo {...} bar {...}" is documented?
by perrin (Chancellor) on Nov 22, 2004 at 02:28 UTC
    The sub prototypes are the reason that I recommend avoiding Error.pm and would not want to see it in the standard library. Take a look at this thread for more.
      This is not so much a reply, as it is an opinionated appendix.

      That's not all Error has to offer though. I use it, so far trying and catching nearly only in tests. I might use try/catch in the future, but so far the implementation of it as an exception object has been pretty useful without the error handling per se.

      The reason I like exception objects is that they promote machine recognizable errors, and thus make error handling/reporting easier.

      Firstly, each error has a class. You can represent groups of errors rather easily with inheritence.

      A certain type of error could inherit from the pseudoclass Error::Recoverable, for example, to allow code catching it to re-attempt the errorneus code. Error categories, for the sake of clean reporting are also nice.

      Another feature of error objects is that they are compound. In my errors, the string is just for the user. I have a unique code for each error (generated by a constant allocator). This is more deterministic than matching regexes on error strings.

      Now, with all this, and the fact that Error is still outwardly compatible with string errors, since the objects stringify, I see no reason why not to promote at least partial use of the Error module.

      -nuffin
      zz zZ Z Z #!perl

        Just to note: you can throw an error object with die. You can throw anything with die.

        eval { die new MyException("foo"); }; if (UNIVERSAL::isa($@, 'MyException') { print "Then my example worked!" }

        Ted Young

        ($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)