Re: _dispatch (was Re: PATCH: [for consideration] TMPSUFFIX)

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Thu, Sep 29, 2016 at 00:30:47 -0700:
> On Sep 29,  6:39am, Daniel Shahaf wrote:
> }
> } It might be easier to just give a flag to eval that means "propagate
> } errflag of the evaluated expression to the calling scope"?  So the eval
> } itself would be aborted/unrolled, too.
> 
> I don't think this is a significant enough problem to warrant changing
> the definition of "eval" (if by "give a flag" you mean "add a -e option"
> for some variant of -e).
> 

Yes, that's what I meant.  In terms if your idea, I think my idea was to
have ERRFLAG_EVAL automatically convert back to ERRFLAG_ERROR iff -e was
passed to eval — i.e., not by default.

> However, if it were possible for the "eval" builtin to know when it
> was inside an "always" construct and propagate a new ERRFLAG_EVAL
> out to where TRY_BLOCK_ERROR could reflect it, that might work.
> The important bit would be that ERRFLAG_EVAL never converts directly
> back into ERRFLAG_ERROR, so if the script ignores TRY_BLOCK_ERROR
> then all errors disappear at the end of the always-block.
> 
> Or something like that.

This makes sense, but wouldn't it also require some way for the always
block to (manually) set ERRFLAG_ERROR again upon an ERRFLAG_EVAL, in
order to "abort enough code" (which was the original issue)?

The interface could be a new builtin, or a setfn on TRY_BLOCK_ERROR; the
important thing is that then the always block finishes ERRFLAG_ERROR
would be set.

Cheers,

Daniel