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

sub modifies_err {
>     my $ctx = context();
>     ...
>     my $err = $@;
>     $ctx->release();
>     $@ = $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!


-Chad

On Sun, Jan 17, 2016 at 9:41 PM, Aristotle Pagaltzis <pagalt...@gmx.de>
wrote:

> * Chad Granum <exodi...@gmail.com> [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
> > automatically...
>
> 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.
>
> Regards,
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>
>

Reply via email to