Re: Propogating Errors / E-Toys

[Michael Schout <ms...@gkg.net>]

Perrin Harkins wrote:
> 
> We've actually discussed this on the list.  It has to do with closures. 
>  Matt gave a presentation about exception handling which covers it and 
> shows a workaround.  You can see it here:
> 
> http://axkit.org/docs/presentations/tpc2001/

Sorry to chime in a little late on this.

But the "Exceptions" slides from the page above are either misleading, 
or I am misunderstainding just what exactly leaks in Error.

The slides above show a "BAD" example of Error.pm as:

sub handler {
     my $r = shift;
     my $count;

     try {
         # use $count in here...
     } catch Error with {
     };
}

However, the eToys article doesnt say that this is unsafe.  What the 
eToys article says is unsafe is code with nested try blocks like this:

my $count;
try {
    ...
    try {
         # use $count in *here*
    };
};

in other words, if I understand the eToys article correctly, the leaks 
only happen if I nest a try block inside another try block.  I have 
experimented some, and it appears to me that this is in fact the case 
($count doesnt get cleaned up if there is a nested try).  But as long as
I dont nest try blocks there doesnt appear to be a leak.

Are Matt's slides misleading on this point?  Or am I missing something here?

Mike

Re: Propogating Errors / E-Toys

[Perrin Harkins <pe...@elem.com>]

Michael Schout wrote:

> in other words, if I understand the eToys article correctly, the leaks 
> only happen if I nest a try block inside another try block.  I have 
> experimented some, and it appears to me that this is in fact the case 
> ($count doesnt get cleaned up if there is a nested try).  But as long as
> I dont nest try blocks there doesnt appear to be a leak.


You are correct, you won't get a leak from the code in Matt's example. 
 What you will get is an unexpected persistence of the value of the 
$count variable.  It will retain its value and not be reset when you 
enter the handler sub again.

There are other problems too, like "return" not doing what you would 
expect when used inside a try block (it only returns from the try block).

- Perrin

Re: Propogating Errors / E-Toys

[Dave Rolsky <au...@urth.org>]

On Wed, 10 Jul 2002, Matt Sergeant wrote:

> Ah, in that case I'm recommending Dave's stuff. It's more flexible and
> doesn't use that irritating -param stuff. Though I have to do a little
> more research to be certain some things are possible (like turning on
> stack traces globally).

Actually, traces are now _always_ created.  And by default they're shown
when stringifying the exception object.

To turn this off you do:

 Exception::Class::Base->Trace(0);

To turn it off for one branch of the hierarchy, do:

 My::Exception::Subclass->Trace(0);

to turn it back on for a branch below that, do:

 My::Exception::Subclass::SubSubClass->Trace(1);

I'm also planning to add some more features to it.

One is something we're using with Mason, where we create convenience subs
for throwing exceptions so we can do:

 param_error "Missing 'foo' in call to new";

instead of:

 HTML::Mason::Exception::Params->throw( error => "Missing 'foo' in call to new" );

plus as an added bonus the first version gets compile time checking of the
sub name, versus runtime checking of the class name in the second.



-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: Propogating Errors / E-Toys

[Matt Sergeant <ma...@sergeant.org>]

On Wed, 10 Jul 2002, Perrin Harkins wrote:

> Matt Sergeant wrote:
> > On Wed, 10 Jul 2002, Fran Fabrizio wrote:
> >>Just to confirm, the end result of Matt's slide presentation was that
> >>Error.pm was good, and you should use it, but you should not use the
> >>try/catch syntax, or at the bare minimum only catch in your outermost
> >>handler.  Is that correct?  We were debating this just yesterday in our
> >>office.
> >
> > Actually my recommendation for this year's talk on exceptions is to just
> > use eval{}; if ($@) {}. It's a little more typing, but at the end of the
> > day closures created by subroutine prototypes are a really bad thing (tm).
>
> I believe he was asking if Error.pm is a good class to use for
> exceptions if you don't use the try/catch keywords.  I think it is.  It
> provides handy methods for storing attributes of the exception and
> getting stack traces, and it's easy to subclass.  You could also use
> Dave Rolsky's Exception::Class, which is pretty similar.

Ah, in that case I'm recommending Dave's stuff. It's more flexible and
doesn't use that irritating -param stuff. Though I have to do a little
more research to be certain some things are possible (like turning on
stack traces globally).

-- 
<!-- Matt -->
<:->Get a smart net</:->

Re: Propogating Errors / E-Toys

[Perrin Harkins <pe...@elem.com>]

Matt Sergeant wrote:
> On Wed, 10 Jul 2002, Fran Fabrizio wrote:
>>Just to confirm, the end result of Matt's slide presentation was that
>>Error.pm was good, and you should use it, but you should not use the
>>try/catch syntax, or at the bare minimum only catch in your outermost
>>handler.  Is that correct?  We were debating this just yesterday in our
>>office.
> 
> Actually my recommendation for this year's talk on exceptions is to just
> use eval{}; if ($@) {}. It's a little more typing, but at the end of the
> day closures created by subroutine prototypes are a really bad thing (tm).

I believe he was asking if Error.pm is a good class to use for 
exceptions if you don't use the try/catch keywords.  I think it is.  It 
provides handy methods for storing attributes of the exception and 
getting stack traces, and it's easy to subclass.  You could also use 
Dave Rolsky's Exception::Class, which is pretty similar.

- Perrin

Re: Propogating Errors / E-Toys

[Matt Sergeant <ma...@sergeant.org>]

On Wed, 10 Jul 2002, Fran Fabrizio wrote:

>
> Just to confirm, the end result of Matt's slide presentation was that
> Error.pm was good, and you should use it, but you should not use the
> try/catch syntax, or at the bare minimum only catch in your outermost
> handler.  Is that correct?  We were debating this just yesterday in our
> office.

Actually my recommendation for this year's talk on exceptions is to just
use eval{}; if ($@) {}. It's a little more typing, but at the end of the
day closures created by subroutine prototypes are a really bad thing (tm).

-- 
<!-- Matt -->
<:->Get a smart net</:->

Re: Propogating Errors / E-Toys

[Fran Fabrizio <ff...@mmrd.com>]

Just to confirm, the end result of Matt's slide presentation was that 
Error.pm was good, and you should use it, but you should not use the 
try/catch syntax, or at the bare minimum only catch in your outermost 
handler.  Is that correct?  We were debating this just yesterday in our 
office.

-Fran

Re: Propogating Errors / E-Toys

[Matt Sergeant <ma...@sergeant.org>]

On Wed, 10 Jul 2002, Michael Schout wrote:

> Perrin Harkins wrote:
> >
> > We've actually discussed this on the list.  It has to do with closures.
> >  Matt gave a presentation about exception handling which covers it and
> > shows a workaround.  You can see it here:
> >
> > http://axkit.org/docs/presentations/tpc2001/
>
> Sorry to chime in a little late on this.
>
> But the "Exceptions" slides from the page above are either misleading,
> or I am misunderstainding just what exactly leaks in Error.

I didn't say "leaks" in my slides. That's what you're misunderstanding. It
merely creates a closure. This *can* lead to leaks, but doesn't always.

I guess at some point I aught to pick up Error::Filter again. Damn that
hard drive crash (which lost the source code I had for a source filter
version of Error.pm, which didn't create closures).

-- 
<!-- Matt -->
<:->Get a smart net</:->