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

[Peter Stephenson <pws@csr.com>]

Bart Schaefer wrote:
> It could also be argued that, if the trap should behave like an "eval",
> it ought to set $? = 1 when an error occurs inside the trap (but still
> not cause an interrupt condition).  The example of bash2 contradicts
> that position.  Can anyone who is reading this try ksh?

ksh appears to set the status to 1.

> Here's a possible compromise:  Use my second patch, but propagate the
> error if and only if we're in the try-block of an always-construct.
> That's guaranteed not to break old code, and continues to behave like
> bash2 in the absence of "always".  Can dotrapargs() determine that it
> is in "always" context without too much trouble?

It can test try_errflag, which is usually -1 when not in an always
block and >= 0 otherwise.  However that's the value of TRY_BLOCK_ERROR
which can be set by the user, so isn't actually guaranteed to be -1
outside.  Either adding another flag not tied to a variable or rejecting
user attempts to set TRY_BLOCK_ERROR when it's current value is less than
zero (and therefore presumably only let it be set to such a number)
would work around this.

But do you mean how can it test if it's in the try block part?  There's
no explicit test for that at the moment, but it's easy to add a variable.

pws


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