HaloO
Yuval Kogman wrote:
We have:
die: throw immediately
fail: return an unthrown exception, which will be thrown
depending on whether our caller, and their caller - every scope
into which this value propagates - is using fatal.
This is enough for normal exception handling.
Is it only me seeing a self-contradiction in 'normal exception'?
But here are some ideas for renaming:
resumeable exception -> retro-fitted pre-condition
or: negotiated pre-condition
or sumply resumption?
My mental picture is that of an outer scope in the call chain
attempting to meet the requirements communicated from an unknown
inner scope and then resuming where the failed pre-condition
was spotted. But I wouldn't require this to be implemented in
a very efficient way! When you need event handling, implement
it. E.g. the fail form needs to preserve the call chain
until the failure is handled. Handling might be as easy as
evaluation in void context or usage of // in a non-fatal scope.
Otherwise a CATCH block is needed. Or perhaps a RESUME block
and a correspondingly enhanced require form? That would integrate
the AUTODEF and friends with the error/exception/control/assertion
system. To illustrate the idea:
if !$file.writeable { require $file.writeable; }
or perhaps even without the if. And then somewhere up the call chain
RESUME
{
when .writeable { make $! writeable; resume }
# more typeish syntax
when File::writeable { make $! writeable; resume }
}
# with type outside
RESUME File::writeable
{
make $! writeable; resume
}
The resume could actually be the default way to exit a RESUME block.
As for recovery - the way it's done can be specialized on top of
continuations, but a continuation for the code that would run had
the exception not been raised is the bare metal support we need to
do this.
Yep, we need to agree on a form how to communicate unmet requirements
outwards. The only entity that comes to my mind that usually matches
requirements is the type system or meta information repository.
Where this gets taken further by (IMHO overly abstract) exception
handling libraries and standardization is a question that
application development kits (e.g. Catalyst, GTK, Cocoa) must
develop a policy for.
Well, yes! A non-trivial framework will install a bunch of types.
A subset of which beeing exception (sub)types. The challenge is then
shifted to inter-framework unification =8)
But one thing that should work is tunneling standard resumption requests
through such a framework.
--
$TSa.greeting := "HaloO"; # mind the echo!
