develooper Front page | perl.perl5.porters | Postings from July 2018

Filterable CXt_EVAL context stack frames

Thread Next
From:
Paul "LeoNerd" Evans
Date:
July 23, 2018 16:46
Subject:
Filterable CXt_EVAL context stack frames
Message ID:
20180723174013.4d3f24c3@shy.leonerd.org.uk
Hi gang,

I'd like to open a discussion on an idea that would allow me to
implement some new abilities in Syntax::Keyword::Try. Principally, the
often-requested ability to somehow filter and dispatch on kinds of
exception.

The idea is that (ignoring how the syntax is spelled) if you could
specify only some kinds of exception be caught, then anything not
matching that specification falls through to the caller:

  try { ... }
  catch (when { isTuesday() }) { ... }
  # if it's not Tuesday, then exceptions fall out here

Now, while I could implement this internally by the moral equivalent of

  catch {
    if(isTuesday()) { CATCHBLOCK }
    else            { die $@ }
  }

that does mean I'm not ignoring the exception, but instead rethrowing
it. This has visible effects on caller() inside $SIG{__DIE__}, the
debugger, and various other things (e.g. Devel::MAT -dump_at_DIE).
These effects are alluded to in

  https://rt.cpan.org/Ticket/Display.html?id=123918


I have a thought about a possible way around this.

I'd like to propose that, in some way, an optional (C-level) filter
function could be attached to a CXt_EVAL stack frame. This would
define a function that returns a Bool with the following effect:

  If the filter is absent or returns true, then the behviour remains
    as it does now.

  If the filter returns false, then perl will ignore this particular
    CXt_EVAL frame and continue unwinding down to the next one, or
    stop at toplevel; i.e. pretends that the eval{} never happened.

Some thorny cornercase questions on its semantics remain; most notably
on the question of what happens if the filter function re├źnters the
interpreter and invokes more perl code which itself will die(); or if
the function invokes Perl_croak() directly. I don't feel that these
questions are big showstoppers, they may be resolveable by "undefined,
don't do that", or they may fall out to be not too different to the
current problems of die inside die handlers or other exception-related
cornercases.

Alternatively, it may eventually be decided that my ongoing (ab)use of
CXt_EVAL to implement the try/catch semantics are becoming a little too
complex (e.g. I already have some hackery to make sure that
return-in-try works as expected), so it may be decided that an
alternative course of action would be to define a truely new CXt_TRY
that can be given the right semantics from the start.

Either way, I feel I've made good headway in trying to bring proper a
try/catch ability into Perl, and I'd like to continue expanding its
abilities.

What do people think?

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About