Infinite catch/retry loop isn't consistently `^C`able

[jpco]

Repro: run and ^C the following a few times.

; catch @ {throw retry} {throw whatever}

Sometimes, ^C stops it the first try, but sometimes it doesn't.

We should probably add tests for running and sigint-ing different kinds of tight loops. Prior art here is #221 and #222. (I also know that the test suite itself doesn't reliably stop on sigint -- is that an es bug, or just weakly-written tests?)

[jpco]

Okay, this is simpler than I thought. When the shell receives a sigint in the "tick" body, it continues looping, but when the shell receives a sigint in the "tock" catcher, it doesn't.

catch @ {
	echo escaped: $*
} {
	catch @ {
		echo tock: $*
		sleep 1
		throw retry
	} {
		echo tick
		sleep 1
		throw continue
	}
}
echo coda

This is due to the way catchers are implemented. Signals are not converted to exceptions during the body of a catcher, which means that, if a signal is sent to the shell while it's executing a catcher, and then the body of the catcher throws, there are TWO pending exceptions, and we have to choose which exception gets precedence over the other.

After #222, the precedence is:

1. Any exception thrown in the catcher, EXCEPT retry
2. Any signal received during the catcher
3. retry

If you replace the throw retry in the example above with a different exception, you'll find that ^C during the "tock" catcher will cause the loop to exit with the exception you used, not the signal. You will also find that echo coda line doesn't run: that's because the signal generated during the "tock" catcher is left pending, so the next SIGCHK() finds it and throws (I believe this is a bug).

So I guess the basic question that needs answering is, what should the precedence for these exceptions be?

Giving all non-signal exceptions, including retry, precedence seems slightly more intuitive to me when I'm in the mindset of writing the catch, but it has two challenges:

• retry loops like catch @ {throw retry} {throw continue} would not be escapable at all with signals (other than kill and friends, of course)
• signals left pending become a problem (fixable with a little code, but needs explicit handling)

Giving signals precedence solves both of those problems automatically. It doesn't quite "solve" the "issue" reported here, but I now think it's the only behavior that makes sense; an exception from the body of a catch is caught and ignored by the @ {throw retry} catcher, but an exception from the catcher escapes. This applies to signals as well as "explicit" exceptions.

So I think the right call here is to always give signals precedence, and also to document how catch interacts with signals in the man page.