On Tue, Oct 5, 2021 at 9:50 AM Caleb Donovick <donovick@cs.stanford.edu> wrote:
2) Some OTHER exception occurs on the reevaluation. It's a chained exception like any other.
Except it's not a chained exception and displaying as such would be VERY confusing IMO. Granted we could easily strip the chained exception and just return the original one. So after reconsideration I agree this is not an issue.
It's only really the fourth case that would be confusing
I generally agree with your analysis but I think this 4th case is more problematic than you think. Given no information I am immediately going to split my assertion so I can see what part is failing. However, if the interpreter gives me incorrect information I am going to be super confused. Most people will not have carefully read section 7.3 of the language reference and will not understand this critical aspect of the execution of assertion statements. They will assume that the interpreter is not lying to them.
I think storing the intermediate results on the stack is vastly preferable to revaluation for this reason.
The trouble is that storing intermediate results is a price paid by every assertion that succeeds, and reevaluating is a price paid only when assertions fail - and the problem you're referring to ONLY happens with broken assertions. Does every assert need to pay the price for the possibility of buggy use of assert? ChrisA