Re: Exception handling and "trap" vs. TRAPNAL()

[Peter Stephenson <pws@csr.com>]

Bart Schaefer <schaefer@brasslantern.com> wrote:
> In zsh prior to 4.1.something, an error condition in an inline trap
> *WAS* passed through to the calling context.  That it now is not, is
> apparently either a broken behavior or an undocumented change, and in
> any case no code written for older zsh could have relied upon errors
> in traps being inconsequential.

I think this is 19575: reading the "-" path in the diff the old behaviour
of setting trapret if errflag is set was there, and a subsequent "errflag =
1" depended solely on that, not being in a function.  Given the description
it doesn't look like the change was intentional, even though arguably it
should be the way it now is.

> [ASIDE:  The bash2 behavior implies that traps set globally outside
> of a function are not supposed to apply within the function context.
> E.g., in bash2 a global INT trap does not prevent the function from
> being interrupted by a SIGINT; instead it handles the signal in the
> context where the trap command was run.  Similarly an ERR trap stops
> being tripped during the body of the function, but remains in effect
> so that it is tripped if/when the function itself returns nonzero.
> This is, almost, the inverse of zsh's "setopt localtraps" behavior.]

This is presumably implementable without too much horror, since we
can already save and restore traps.  It would probably now need to be an
option, though.

> Raúl ... the important point that you're missing is that zsh doesn't
> really have or handle exceptions.  Peter's throw/catch functions are
> simulations of exception behavior using a mechanism that is far less
> powerful than true exception handling.

Yes, it's all just based on testing a single variable and relying on the
fact that zsh has to unwind the state during an error anyway.  Maybe the
zshcontrib entry needs more cautionary wording.

> The zsh "always" syntax could -- and perhaps even should -- have been
> implemented equally well as a new syntax for the "eval" builtin, much
> like Perl's "eval" can be followed by a curly-bracketed block instead
> of a string.

That's not particularly natural in zsh.

  eval { ... }

would mean that "eval" could no longer be a true builtin but would have to
be treated as a reserved word early in parsing.  We can second-guess the
later stages in processing (is eval disabled?), so probably it can be done
without major grief, but the zsh syntax isn't really comparable to Perl.

> (In fact, a very useful extension would
> be to add an EVAL_ERROR variable that is 1 if an "eval" stopped with
> an error, and 0 if "eval" finished normally, so that an error could be
> distinguished from "eval false".)

This, presumably, is simple.

> Presently (that is, without either of my patches), a TRAPNAL function
> handles error conditions like a function call, whereas an inline trap
> handles error conditions like an "eval" statement.  That's defensible,
> in a way, because a "trap" command *looks* like an "eval" statement;
> it contains a string that is evaluated as commands.  It could even be
> explained that way in the docs, so that you would have understood why
> your sample script didn't work.

Yes, this all sounds rational.

> Given all of this plus the bash2 behavior, I'm inclined to add a few
> more words to the documentation and apply *neither* of the patches
> from workers/21804.  Further, *IF* we were going to choose one of
> those patches to apply, I'd say it should be the first one, to make
> TRAPNAL ignore errors too.

It looks like the reason for the error to be propagated is receding into
history and I'd be perfectly happy with that patch.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com