$@ abuse in 5.14

ribasushi, mst, and I have discussed the issue of modules wanting to
know about unwinding in progress, and reached some interim conclusions.

Regarding those modules that have so far used $@ to determine whether
unwinding is due to an exception, I accept the practical need to keep them
working in 5.14 at least as well as they work up to 5.12.  (For reasons
previously discussed ad nauseam, they don't qualify as fully working
in this respect.)  ribasushi is quite open to them needing to use a
different strategy according to the Perl version.

The type of arrangement that would be most mutually satisfactory would
be a new introspective interface that explicitly describes the reason for
whatever unwinding operations are currently in progress.  We've discussed
various possibilities for this at length, but most of the details were a
bit off.  (For example, in one round I was mistaken about some important
details of how the context stack operates.)  In the past few weeks I've
intermittently looked at the core with the intention of implementing
something, but it's turned out to be more difficult than I expected,
and I still don't have a concrete proposal.

We have identified a least-bad stopgap solution: the core could set $@
to the exception being thrown just before exceptional unwinding, but
then ignore this and set $@ again where it currently does, just before
final transfer of control.  This doesn't address the inherent defects of
the up-to-5.12 $@ abuse, but it would keep the affected modules working
exactly as well as they did before, without any module code changes.
I am unhappy about this giving $@ an extra job, where much of my exception
cleanup was about relieving $@ of conflicting jobs.  I would therefore
not want this to be a permanent resolution, but I'm happy that it's
fairly unobtrusive as hacks go.

Our agreed position is that I should continue to seek a clean interface
for this, but if that fails then we'd like 5.14 to have the least-bad
stopgap solution.  In that event, most likely we'd be able to come up with
something clean for 5.16, which could replace the stopgap.  I expect that
a clean solution and this stopgap would both qualify as uncontentious,
so our deadline is probably 2011-02-20 (5.13.10) rather than 2010-12-20
(5.13.8).  Jesse, comments?

It may also be sensible to put the stopgap into core now, so that the
affected modules can be properly tested against 5.13.{8,9}.  If this is
done, and I subsequently come up with a clean interface, I'd be seeking
to replace the stopgap immediately with the clean interface.

-zefram

• $@ abuse in 5.14 by Zefram
• Re: $@ abuse in 5.14 by Jesse Vincent
• Re: $@ abuse in 5.14 by Zefram
• Re: $@ abuse in 5.14 by Tony Cook
• RE: $@ abuse in 5.14 by Jan Dubois