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

[Bart Schaefer <schaefer@brasslantern.com>]

On Oct 1,  5:37pm, DervishD wrote:
} Subject: Re: Exception handling and "trap" vs. TRAPNAL()
}
}     Hi Peter :)
}  * Peter Stephenson <pws@csr.com> dixit:
} > Add some "print"s to the trap to see when it's triggering.
} 
}     The trap is triggering just in the "false" statement, and the
} TRAPZERR works perfectly, it's the "trap" kind which is failing.

I ran this with "set -x" (much better than inserting print statements)
and it's clear that the "trap" command version of the trap is not
tripping the "always" block:

+./script:34> false
+./script:34> throw DEFAULT
+throw:34> typeset -g 'EXCEPTION=DEFAULT'
+throw:34> readonly 'THROW=0'
+throw:34> ((  TRY_BLOCK_ERROR == 0  ))
throw:34: read-only variable: THROW
+throw:34> THROW='' 
+./script:35> throw EXCEPTION

The problem is this snippet in signals.c:

    } else if (errflag)
	trapret = 1;
    execrestore();
    lexrestore();

    if (trapret > 0) {
	if (isfunc) {
	    breaks = loops;
	    errflag = 1;
	} else {
	    lastval = trapret-1;
	}

We start that section with errflag == 1 and set trapret = 1, but then
at lexrestore(), errflag is reset to zero, and because isfunc is false,
it's not set back to 1 again.  After unwinding out of the trap handler,
execution of the try block finds errflag == 0, and proceeds rather than
skipping ahead to the always block.

So the question is:  Why ignore errors that occur in inline traps?

} Can I do anything to make it work (except patching zsh)?

I don't think so.

} Is there any other way of throwing exceptions automagically when a
} command returns a non-zero status

No.