zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
To: zsh-workers@sunsite.dk
Subject: Re: Exception handling and "trap" vs. TRAPNAL()
Date: Sat, 01 Oct 2005 20:10:33 +0100	[thread overview]
Message-ID: <20051001191035.2A4F48673@pwstephenson.fsnet.co.uk> (raw)
In-Reply-To: <1051001183818.ZM27904@candle.brasslantern.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]

Bart Schaefer wrote:
> So the question is:  Why ignore errors that occur in inline traps?

I'm glad you looked at this rather than me...

Correct me if I'm wrong, but I don't think that's quite the question,
which is in two parts: (1) why ignore errors in traps (the save/restore
behaviour seen regardless of the trap style) (2) why flag an error only
when returning a non-zero status from a function-style trap (the
explicit setting of "errflag" when returning with non-zero status from
such a trap).

The answer to (1) is that traps are present as error handlers (of some
sort and for some debatable value of "error") and to avoid confusing
matters the error is taken from the code surrounding the trap, not the
trap itself.  Traps are supposed to operate in a sort of semi-permeable
sandbox.  (Yes, I know that's meaningless.)

The answer to (2) is this, from the manual regarding function-style traps:

  The return status from the function is handled specially.  If it
  is  zero, the signal is assumed to have been handled, and execu‐
  tion continues normally.  Otherwise, the normal  effect  of  the
  signal  is  produced; if this causes execution to terminate, the
  status returned to the shell is the  status  returned  from  the
  function.

So the whole behaviour that DervishD is seeing is a side affect of the
fact that this:

  TRAPZERR() { throw DEFAULT; }

finishes by executing a command with non-zero status, the throw, causing
the special behaviour described above.

You can certainly argue that the "normal effect" of a ZERR trap is not
to cause an error, and it's certainly possible to argue that yet more
hacked-up special cases and additional bug-prone complexity in the trap
code are warranted.  However, I'm still not convinced this is going
anywhere I want to go.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk


  reply	other threads:[~2005-10-01 19:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050929200741.GA1156@DervishD>
     [not found] ` <20050930124130.45eb0463.pws@csr.com>
     [not found]   ` <20051001153756.GA12183@DervishD>
2005-10-01 18:38     ` Bart Schaefer
2005-10-01 19:10       ` Peter Stephenson [this message]
2005-10-01 20:41         ` DervishD
2005-10-01 22:44         ` Bart Schaefer
2005-10-02  8:06           ` DervishD
2005-10-01 20:28       ` DervishD
2005-10-02  4:40         ` Bart Schaefer
2005-10-02  8:13           ` DervishD
2005-10-02 19:09           ` Peter Stephenson
2005-10-02 19:55             ` Bart Schaefer
2005-10-02 23:00               ` DervishD
2005-10-03  1:37                 ` Bart Schaefer
2005-10-03  8:57                   ` Peter Stephenson
2005-10-03 14:51                     ` Bart Schaefer
2005-10-03 15:10                       ` Peter Stephenson
2005-10-03 16:50                         ` Bart Schaefer
2005-10-03  9:01                   ` DervishD
2005-10-03 16:21                     ` Bart Schaefer
2005-10-03 17:59                       ` DervishD
2005-10-04 16:31                         ` Bart Schaefer
2005-10-04 17:29                           ` DervishD
2005-10-04 17:34                             ` Peter Stephenson
2005-10-04 17:46                               ` DervishD
2005-10-01  8:01 DervishD
  -- strict thread matches above, loose matches on Subject: below --
2005-10-01  7:45 DervishD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051001191035.2A4F48673@pwstephenson.fsnet.co.uk \
    --to=pws@pwstephenson.fsnet.co.uk \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).