Whose RFC deals with this?
Why not call them throw and catch, like everywhere else,
and reccomend them over die? In fact Die could be defined
in terms of throw
sub die(@){ throw(generic_fatal,$!,@_) }
*****
Further discussion in the thread discussed the idea of returning
to the point of throwing, as the routine noting the error might
be supposed to ignore this error, the author of this comment
(Bennett Todd?) implied that that is how throwing and catching
is supposed to work.
Which seems to mean that code that throws has to run not knowing
if the catchers threw back, instead of being able to trust that
everything has gone right so far.
Having an error handler return to the point of error sound to me
like a short term win with long term complexity problems.
I imagine that the default handler for any exception is what we
now know as C<die> but that it could be overloaded within a scope
by a C<catch> command, which would take two arguments, the first
a SV or a container of them, which would (each) be a type-specifier
(a text string or a compiled optimization of such if possible)
and the second some code to run, that gets passed the rest of
the arguments at exception time.
There's no calling back, if
you need to support that kind of thing you can construct it by explicitly
stashing the items that will be needed by the rest of the routine and
calling the continuator with the stash from w/in the handler. That way if
my code is
open $IOhandle, $Filename or throw IO, "cannot open $Filename";
I can rely on that throw protecting the rest of my routine from trying
to read from a null IOhandler because some fool wrapped my routine with
a returning error handling routine for IO.
Bennet's continuation would be easier if we had access to a special
$CORE::scope value that was a pointer to the immediate environment,
then you could include that in what you throw and the error handler could
pass it to any of a variety of different continuations depending on the
exact nature of the error.
> Why not, then, introduce non-fatal errors and a new keyword to throw them?
> Something like quit(), which could take an error class, an error identifier
> (a number or short string or something) and a message. It'd work like a
> bare return, but also stick something in $@, and could be trappable. (Quit
> with one parameter would default the class to generic, and the identifier
> to unknown)
>
> This way, when something needs to bail with a non-fatal error it could:
>
> quit('io', 'READERROR', "Unable to read from file $foo");
>
> and the code calling the sub could, if it wanted, could do a plain:
>
> $foo = some_sub($file);
>
> or:
>
> {
> use fatal;
> eval {
> $foo = some_sub($file);
> };
> if ($@) {
> if ($@->nonfatal) {
> # handle non-fatal errors
> }
> }
> }
>
> or something like that.
>
> *) Define a set of c
>
> Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq
