The recipe
catch $script m o
return -options $o $m
lets me reproduce what evaluation of $script
alone would do. Other than the variables m and o
and some trivial unimportant things, they are
indistinguishable. Most importantly to me
they leave the same -errorinfo value in the
interp to be captured by another enclosing [catch].
I want some set of options to [try] to be able to
do the same thing. Right now, that appears
impossible because [try] seems to be pretty
insistent on leaving decorations on the errorInfo
value.
Since I have the [catch; return] combo that does what
I want, you might ask why that's not enough. Well
there are some places where only a single command
will do.
A [tailcall try $script] that didn't leave [try] droppings
on the stack trace would be nice.
I'm not sure what the right thing to do here is.
The offending message is tclCmdMZ.c:4393 (i.e., the *second* place in the function TryPostBody that looks like it is relevant; the first is in the unwind/limit handling).
As a side note, it turns out that [info errorstack] is unaffected (being only concerned with scope levels, not with internal constructs like [while] or, for that matter, [try] or [catch]):
% proc f {} g
% proc g {} {try {error FOO} on error {m o} {return -options $o $m}}
% f
FOO
% info errorstack
INNER {returnStk FOO} CALL g CALL f
% proc f2 {} g2
% proc g2 {} {error FOO}
% f2
FOO
% info errorstack
INNER {returnStk FOO} CALL g2 CALL f2