perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Förtsch <>
Subject Re: svn commit: r1299669 - in /perl/modperl/trunk: Changes src/modules/perl/modperl_error.c xs/APR/Pool/APR__Pool.h xs/Apache2/ServerUtil/Apache2__ServerUtil.h
Date Tue, 13 Mar 2012 09:46:58 GMT
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! (

Like fantasy?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message