Terminal interrupts should not fall through "try" and "?(...)"
Example (pardon my non-standard prompt and value-out-indicator):
⬥ try { read-upto "\n" } finally { put done }
^C
⮕ "\n"
Exception: interrupted
[tty], line 1: try { read-upto "\n" } finally { put done }
⬥
In this example, the builtin command read-upto does manage to capture the interrupt, finish its work, and re-throw the error. But the try construct fails to run the cleanup code. The same happens when it executes an external command, such as sleep 10.
Perhaps this is by design: If terminal interrupts can be captured, a try … except inside a loop could lead to a situation from which there is no escape. However, even if so, I think at least the finally block should be allowed to run.
The scenario I had in mind, is this:
pw=(try { stty -echo; print 'password: ' >/dev/tty; read-upto "\n" } finally { stty echo })
where it is important that the cleanup action is run no matter what.
This is indeed a bug, and it has something to do with how terminal interrupts are relayed to Elvish functions.
Aiming to fix this before 0.14.