diff options
author | Zefram <zefram@fysh.org> | 2010-05-05 20:26:01 +0100 |
---|---|---|
committer | Jesse Vincent <jesse@bestpractical.com> | 2010-05-08 16:39:22 -0400 |
commit | 9d5401cef7488142a773a2e8980f9763da4a2cae (patch) | |
tree | 47b59d0395699ee9569f46f805778ec099a1a8f2 /pod | |
parent | 9e5bbba0de25c01ae9355c7a97e237602a37e9f3 (diff) | |
download | perl-9d5401cef7488142a773a2e8980f9763da4a2cae.tar.gz |
perldelta item on reliable exception handling
Diffstat (limited to 'pod')
-rw-r--r-- | pod/perl5131delta.pod | 50 |
1 files changed, 50 insertions, 0 deletions
diff --git a/pod/perl5131delta.pod b/pod/perl5131delta.pod index 1e4070375a..e907744463 100644 --- a/pod/perl5131delta.pod +++ b/pod/perl5131delta.pod @@ -50,6 +50,56 @@ XXX New core language features go here. Summarise user-visible core language enhancements. Particularly prominent performance optimisations could go here, but most should go in the L</Performance Enhancements> section. +=head2 Exception Handling Reliability + +Several changes have been made to the way C<die>, C<warn>, and C<$@> +behave, in order to make them more reliable and consistent. + +When an exception is thrown inside an C<eval>, the exception is no +longer at risk of being clobbered by code running during unwinding +(e.g., destructors). Previously, the exception was written into C<$@> +early in the throwing process, and would be overwritten if C<eval> was +used internally in the destructor for an object that had to be freed +while exiting from the outer C<eval>. Now the exception is written +into C<$@> last thing before exiting the outer C<eval>, so the code +running immediately thereafter can rely on the value in C<$@> correctly +corresponding to that C<eval>. + +Likewise, a C<local $@> inside an C<eval> will no longer clobber any +exception thrown in its scope. Previously, the restoration of C<$@> upon +unwinding would overwrite any exception being thrown. Now the exception +gets to the C<eval> anyway. So C<local $@> is safe inside an C<eval>, +albeit of rather limited use. + +Exceptions thrown from object destructors no longer modify the C<$@> +of the surrounding context. (If the surrounding context was exception +unwinding, this used to be another way to clobber the exception being +thrown. Due to the above change it no longer has that significance, +but there are other situations where C<$@> is significant.) Previously +such an exception was sometimes emitted as a warning, and then either +string-appended to the surrounding C<$@> or completely replaced the +surrounding C<$@>, depending on whether that exception and the surrounding +C<$@> were strings or objects. Now, an exception in this situation is +always emitted as a warning, leaving the surrounding C<$@> untouched. +In addition to object destructors, this also affects any function call +performed by XS code using the C<G_KEEPERR> flag. + +C<$@> is also no longer used as an internal temporary variable when +preparing to C<die>. Previously it was internally necessary to put +any exception object (any non-string exception) into C<$@> first, +before it could be used as an exception. (The C API still offers the +old option, so an XS module might still clobber C<$@> in the old way.) +This change together with the foregoing means that, in various places, +C<$@> may be observed to contain its previously-assigned value, rather +than having been overwritten by recent exception-related activity. + +Warnings for C<warn> can now be objects, in the same way as exceptions +for C<die>. If an object-based warning gets the default handling, +of writing to standard error, it will of course still be stringified +along the way. But a C<$SIG{__WARN__}> handler will now receive an +object-based warning as an object, where previously it was passed the +result of stringifying the object. + =head1 New Platforms XXX List any platforms that this version of perl compiles on, that previous |