Bug #66536 for Try-Tiny: $_ leaks into finally

Thu Mar 10 20:51:05 2011 mschwern [...] cpan.org - Ticket created

Subject:

$_ leaks into finally

What arguments finally() gets and what the status of $_ isn't clear in the docs, but it seems like it gets the same as catch. I went and used $_ but discovered that it isn't localized like it is in catch. So a stray $_ can interfere. Test attached.

Subject:

test.plx

Download test.plx
application/octet-stream 227b

Message body not shown because it is not plain text.

Wed Apr 27 18:45:33 2011 DOY [...] cpan.org - Correspondence added

This is actually intentional behavior. Inside a catch block, you know that an exception has been thrown, and that its value is in $_, so you can just use it directly. Inside a finally block, however, an exception might not have been thrown, but testing for undef is not sufficient to tell whether there was an exception (see "$@ might not be a true value" under "BACKGROUND"). This is why scalar(@_) == 0 when an exception was not thrown. If you're already checking @_ like that, however, (and you should be, if you care about possible exceptions), then there's no reason you can't get the actual error out of @_ as well. I've updated the docs and tests in 0.10 to reflect this.

Wed Apr 27 18:45:34 2011 The RT System itself - Status changed from 'new' to 'open'

Wed Apr 27 18:45:34 2011 DOY [...] cpan.org - Status changed from 'open' to 'resolved'

Thu Apr 28 10:21:00 2011 mschwern [...] cpan.org - Correspondence added

On Wed Apr 27 18:45:33 2011, DOY wrote: Show quoted text

> This is actually intentional behavior. Inside a catch block, you know > that an exception has been thrown, and that its value is in $_, so you > can just use it directly. Inside a finally block, however, an exception > might not have been thrown, but testing for undef is not sufficient to > tell whether there was an exception (see "$@ might not be a true value" > under "BACKGROUND"). This is why scalar(@_) == 0 when an exception was > not thrown. If you're already checking @_ like that, however, (and you > should be, if you care about possible exceptions), then there's no > reason you can't get the actual error out of @_ as well. I've updated > the docs and tests in 0.10 to reflect this.

I would like to argue that while that's all true, the interfaces to catch and finally are awfully similar. People are likely to assume they work the same and try to use $_ in finally. This is far more likely than someone throwing an object that is boolean overloaded to false which I have never seen. In addition, the user failure case is silent and/or confusing. If a user codes a finally block expecting $_ to be the exception, either $_ will be unset and the finally block will quietly ignore the exception, or $_ will be set by something global and they'll (maybe) get garbage. If the goal is to reduce user mistakes, making finally work like catch will have a greater effect. In addition, the docs should steer the user *away* from using $_ altogether except in the given/when case.

Thu Apr 28 10:21:01 2011 The RT System itself - Status changed from 'resolved' to 'open'

Tue May 03 08:38:59 2011 bohica [...] ntlworld.com - Correspondence added

On Wed Apr 27 18:45:33 2011, DOY wrote: Show quoted text

> This is actually intentional behavior. Inside a catch block, you know > that an exception has been thrown, and that its value is in $_, so you > can just use it directly. Inside a finally block, however, an

exception Show quoted text

> might not have been thrown, but testing for undef is not sufficient to > tell whether there was an exception (see "$@ might not be a true

value" Show quoted text

> under "BACKGROUND"). This is why scalar(@_) == 0 when an exception was > not thrown. If you're already checking @_ like that, however, (and you > should be, if you care about possible exceptions), then there's no > reason you can't get the actual error out of @_ as well. I've updated > the docs and tests in 0.10 to reflect this.

Where can we see the updated docs and tests in 0.10 as githib seems to stop at 0.06? Like mschwern I think I would have preferred finally and catch to be aligned but I never made that clear in the rt I originally added for finally. Martin -- Martin J. Evans Wetherby, UK

Thu Jul 04 05:14:14 2013 ribasushi [...] leporine.io - Correspondence added

On Tue May 03 08:38:59 2011, MJEVANS wrote: Show quoted text

> Where can we see the updated docs and tests in 0.10 as githib seems to > stop at 0.06?

https://github.com/ribasushi/try-tiny/commit/658a90e5 Show quoted text

> > Like mschwern I think I would have preferred finally and catch to be > aligned but I never made that clear in the rt I originally added for > finally. >

I do not think aligning them is possible for technical reasons - finally's are scope-guards. Their execution happens in a special type of vacuum, where $@ and $_ are even more volatile. The original issue aside - consider this problem: https://github.com/ribasushi/try-tiny/commit/5f5e92c0e I am hoping to have this incorporated into the next Try::Tiny release (https://github.com/doy/try-tiny/pull/7) Cheers

Thu Jul 04 05:14:32 2013 ribasushi [...] leporine.io - Cc RIBASUSHI added

Thu Jul 04 12:29:32 2013 DOY [...] cpan.org - Status changed from 'open' to 'resolved'