Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Scope-Guard CPAN distribution.

Report information
The Basics
Id: 99438
Status: resolved
Priority: 0/
Queue: Scope-Guard

People
Owner: Nobody in particular
Requestors: perl [...] toby.ink
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.20
Fixed in: (no value)



Subject: can't throw an exception in a guard
I'd expect this to say "Hello" and then die "Goodbye", but the die never happens. use v5.14; use Scope::Guard; $|++; do { my $guard = Scope::Guard->new(sub { say "Hello"; die "Goodbye"; }); 42; }; Strangely if you `use warnings`, it *does* die, but only in global cleanup.
Scope::OnExit is similar, so it seems to be a general Perl issue rather than specific to Scope::Guard. Guard <http://metacpan.org/release/Guard> doesn't suffer from this project, and BenGoldberg on #perl-help on IRC has also suggested a solution based on Variable::Magic.
Hi, Toby. Thanks for reporting this. As you say, it works if warnings are enabled, and has done since perl 5.6.1: $ perldoc perl561delta: Show quoted text
> Failures in DESTROY() > When code in a destructor threw an exception, it went unnoticed > in earlier versions of Perl, unless someone happened to be > looking in $@ just after the point the destructor > happened to run. Such failures are now visible as warnings > when warnings are enabled.
$ cat test.pl 01 use strict; 02 use warnings; 03 use v5.14; 04 05 use Scope::Guard; 06 07 $|++; 08 09 do { 10 my $guard = Scope::Guard->new(sub { say "Hello"; die "Goodbye"; }); 11 42; 12 }; $ perl ./test.pl Useless use of a constant (42) in void context at test.pl line 11. Hello (in cleanup) Goodbye at test.pl line 10. I'm happy to consider a documentation patch which mentions this, but otherwise I think "don't do that then" applies :-) $ perldoc perlstyle Show quoted text
> The most important thing is to run your programs under the -w flag at > all times. You may turn it off explicitly for particular portions of > code via the "no warnings" pragma or the $^W variable if you must. > You should also always run under "use strict" or know the reason why > not.