Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Exception handling and "trap" vs. TRAPNAL()
- X-seq: zsh-workers 21807
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: Exception handling and "trap" vs. TRAPNAL()
- Date: Mon, 3 Oct 2005 09:57:38 +0100
- In-reply-to: <1051003013758.ZM3107@xxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- Organization: Cambridge Silicon Radio
- References: <20050929200741.GA1156@DervishD> <20050930124130.45eb0463.pws@xxxxxxx> <20051001153756.GA12183@DervishD> <1051001183818.ZM27904@xxxxxxxxxxxxxxxxxxxxxxx> <20051001202856.GA134@DervishD> <1051002044052.ZM28373@xxxxxxxxxxxxxxxxxxxxxxx> <20051002190940.437F9866F@xxxxxxxxxxxxxxxxxxxxxxxx> <1051002195518.ZM2163@xxxxxxxxxxxxxxxxxxxxxxx> <20051002230027.GA194@DervishD> <1051003013758.ZM3107@xxxxxxxxxxxxxxxxxxxxxxx>
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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@xxxxxxx> 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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author