From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3578 invoked from network); 1 Oct 2005 22:44:23 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 1 Oct 2005 22:44:23 -0000 Received: (qmail 55765 invoked from network); 1 Oct 2005 22:44:17 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 1 Oct 2005 22:44:17 -0000 Received: (qmail 9254 invoked by alias); 1 Oct 2005 22:44:14 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 21798 Received: (qmail 9244 invoked from network); 1 Oct 2005 22:44:13 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 1 Oct 2005 22:44:13 -0000 Received: (qmail 55458 invoked from network); 1 Oct 2005 22:44:13 -0000 Received: from vms040pub.verizon.net (206.46.252.40) by a.mx.sunsite.dk with SMTP; 1 Oct 2005 22:44:12 -0000 Received: from candle.brasslantern.com ([71.116.81.225]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0INP00CTZDTKMSY0@vms040.mailsrvcs.net> for zsh-workers@sunsite.dk; Sat, 01 Oct 2005 17:44:09 -0500 (CDT) Received: from candle.brasslantern.com (IDENT:schaefer@localhost [127.0.0.1]) by candle.brasslantern.com (8.12.11/8.12.11) with ESMTP id j91Mi76B028129; Sat, 01 Oct 2005 15:44:07 -0700 Received: (from schaefer@localhost) by candle.brasslantern.com (8.12.11/8.12.11/Submit) id j91Mi69K028128; Sat, 01 Oct 2005 15:44:07 -0700 Date: Sat, 01 Oct 2005 22:44:06 +0000 From: Bart Schaefer Subject: Re: Exception handling and "trap" vs. TRAPNAL() In-reply-to: <20051001191035.2A4F48673@pwstephenson.fsnet.co.uk> To: Peter Stephenson , zsh-workers@sunsite.dk Message-id: <1051001224406.ZM28125@candle.brasslantern.com> MIME-version: 1.0 X-Mailer: Z-Mail (5.0.0 30July97) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable References: <20050929200741.GA1156@DervishD> <20050930124130.45eb0463.pws@csr.com> <20051001153756.GA12183@DervishD> <1051001183818.ZM27904@candle.brasslantern.com> <20051001191035.2A4F48673@pwstephenson.fsnet.co.uk> Comments: In reply to Peter Stephenson "Re: Exception handling and "trap" vs. TRAPNAL()" (Oct 1, 8:10pm) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 On Oct 1, 8:10pm, Peter Stephenson wrote: } } Bart Schaefer wrote: } > So the question is: Why ignore errors that occur in inline traps? } = } 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. Yes, but the "error" of a non-zero command status is not the same as a shell-level error (syntax or what have you). } 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 It could be argued that, in the presence of an "always" block, the function should not be considered to have "finished" at all. The shell-level error is supposed to have stopped execution; the implict "return $?" never happened, the return status of the function is not defined, and we're in no-man's land. The trouble, of course, is that shell-level errors are not really exceptions, an "always" block is not really an exception handler, and nothing is actually "thrown" by "throw", so none of the assumptions are valid that Ra=FAl is making based on the names "throw" and "catch". And the implementation simply can't stop execution and unwind to the "always" block the way a real exception system would. = } 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. Well, that's just it. An even stronger argument than the no-man's land proposition, is that errflag should *not* be propagated out of a ZERR trap. This would not accomplish what Ra=FAl wants, because it would mean= that *neither* TRAPZERR nor "trap ... ZERR" would be capable of "raising an exception" -- in effect we'd be removing a special-case, not adding one. } else if (trapreturn >=3D 0 && !isfunc) { /* * Context was an inline trap. If an explicit return value * was used, we need to set `lastval'. Otherwise we use the * value restored by execrestore. In this case, all return * values indicate an explicit return from the current function, * so always handle specially. trapreturn is always restored by * execrestore. */ trapret =3D trapreturn + 1; } else if (errflag) trapret =3D 1; I'm not sure, though, that there isn't some other kind of real signal that depends on that snippet. } However, I'm still not convinced this is going anywhere I want to go. The behavior should be consistent, is all.