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