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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 3, 11:01am, DervishD wrote:
}
}     I know, I know, but AFAIK the "always" block works more or less
} the same as exception handling does in other languages.

Less, not more.  The problem is that in a language with real exceptions,
the difference between an error and an exception is well-defined, and it
is usually possible to have errors without exceptions and vice-versa.
Zsh's "always" block is an error handler, not an exception handler, and
PWS's functions are overloading the meaning of "error".

} > }   Propagating "errflag" may break current code only if that code is
} > } using an inline trap which "returns" a value and that error value is
} > } ignored on purpose.
} > That's not quite correct.  Remember, an inline trap using the "return"
} > builtin actually causes the surrounding/calling context to return
} 
}     That's why I was quoting "return": I didn't mean a literal
} "return" command, but a way of returning a value to the current code.

Yes, but there *isn't* any way of returning a value to the surrounding
code -- unless you mean something like setting $REPLY.  So your basis
for the statement is a practical impossibility.

} If $? is restored, then there is not easy way of returning the error,
} but that's good because then propagating "errflag" shouldn't break
} current code, am I wrong?

Yes, unfortunately, you're wrong.

}     But if you propagate the error, you won't break such code. I
} mean, even with your patch, this code...
} 
}     trap 'readonly VAR; VAR=0' ZERR
} 
}     print "HERE"
}     false
}     print "HERE AGAIN"
} 
}     ...will print both strings.
   
In 4.0.6, or with my second potential patch, that prints only "HERE"
(plus the error message about the readonly assignment).  In 4.2.5, it
prints both strings.  In bash2, it also prints both strings.  Anything
that relies on the 4.2.5 or bash2 behavior will break if we go back to
propagating the error as was done in 4.0.6.

} O:)) As far as I understan, "errflag" just signals the error and
} propagate it to the current execution environment (for inline traps,
} I mean), but doesn't make the shell abort :?

It doesn't make the shell *exit*, but it does stop execution in the
way that would jump into an "always" block.  (If it did not, how
would it solve your problem?)  In the absence of the "always", it
simply bails out of the current context.  The "always" block is a way
to intercept the "bail out" action, but the bail-out happens whether
"always" is there or not.
 
}     If no patch is applied I can still use TRAPNAL's for throwing
} exceptions, but I must think a way of doing that with inline traps,
} which I think it's impossible because the value of TRY_BLOCK_ERROR is
} reset.

You're right, it's impossible.  You'll have to think about how you
would write the code if you never had "always" in the first place,
and write it that way.