Just realized my response may not have been clear. My response assumes that
context() DOES store $!, $@ and $?. And that release() restores them. I was
saying that it is easy to get around this magic in the very rare case you
want to. Most cases will not have any need to work around it as it is a
typically desired behavior.
On Sun, Jan 17, 2016 at 9:53 PM, Chad Granum wrote:

I can add a complex mechanism, or someone can just do this:

sub modifies_err {
my $ctx = context();
my $err = $@;
$@ = $err;
return ...;

It is unlikely anyone would want to have $@, $!, and $?, all at once, but
just as easy to manually maintain them. Wanting to preserve any, let alone
all 3 is rare enough, and easy enough, that I think adding a mechanism into
release() or context() would be noise. Add to this the fact that context()
and release() are called so often, and have been written so very carefully
to be as fast as possible, I am not convinced this mechanism is necessary.

Then again, if you /really/ want the mechanism in $ctx, I can add
$ctx->release_preserving (naming is hard, give me a better one) which does
have the behavior... but at that point, which behavior do you want,
preserve one, preserve all, preserve what is requested in arguments? Once
again, seems over-complicated for something done so rarely, and so easy to
just do without a mechanism.

rjbs and I actually talked about this Friday. He asked me how a function
could set $@ if it wanted to, I showed him a sample like the one above and
his response was:

<Exodist> ->release; $@ = $err;
<rjbs> oh, of course
<rjbs> Ha, right. I'm dumb.
<rjbs> Thanks!

On Sun, Jan 17, 2016 at 9:41 PM, Aristotle Pagaltzis wrote:

* Chad Granum [2016-01-12 04:20]:
That said, it just occured to me that this can possibly be
accomplished by having a context store $! And $@ when it is obtained,
then restore them when it is released, which would avoid needing to
use local everywhere, and still preserve them for all tools
I actually like the magic Kent is wary about in this instance, as it
makes it easier for test functions to get this right without each of
them having to carry extra boilerplate. But this also means that a test
function which explicitly *wants* to change these variables has to fight
the framework for it. So maybe there ought to be a mechanism to request
that they not be restored on context release.

Aristotle Pagaltzis // <http://plasmasturm.org/>

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 23 of 28 | next ›
Discussion Overview
groupcpan-workers @
postedJan 12, '16 at 12:53a
activeJan 18, '16 at 10:52p



site design / logo © 2018 Grokbase