On Monday, 12 March 2012 11:03:52 Fred Moyer wrote:
> I'm not clear on the end user implications of this - how will the
> error be presented now?
The only difference _should_ be like this. Suppose this code:
my $p=APR::Pool->new;
$p->cleanup_register(sub {die \"huhu"});
eval {undef $p};
Now, before the patch $@ would be a simple scalar string containing something
like "SCALAR(0x6375c8)" that is the stringified representation of \"huhu".
That is before the change C<'' eq ref $@> is true.
After the change $@ will contain the reference itself. Thus, C<print $@> will
still print the same string as before except for the trailing " at ... line
...\n" perhaps. But C<print ${$@}> will now print "huhu" and C<'SCALAR' eq ref
$@> is true.
Of course you can also throw other references, hashes, arrays or objects.
In general, I'd see it as a bug to be limited to exception strings only
because an arbitrary XS layer in the call hierarchy unconditionally
stringifies all exceptions.
However, on a second thought, I doubt that we have tests in our test suite
that actually check what happens if a PerlCleanupHandler or a pool cleanup
handler throw an exception. That may be worth some effort to investigate and
implement such tests.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
