[gumby]

The reason they care called "exceptions" is they are not part of the normal behavior of the function (/block, algorithm) and aren't something that can be handled locally. Something that is exceptional is unusual, out of the typical scope of things. In English there is a phrase, "the exception to the rule" -- because the rule is what normally happens.

So if you are trying to hold a lock you don't throw an exception, you just wait and try again. Perhaps you can't reach that host; try again a few tiles before giving up and throwing an exception. But if you try to write to removable media and the device won't open, all, your program isn't going to mount a tape itself: throw an exception and let the problem be handled at a higher level.

[talaketu]

English also has the phrase "the exception proves the rule" - and it's just swell when our general code handles special cases.

I would have not have thought an unreachable host was exceptional, given that it's quite normal.

[gumby]

In this aphorism, “prove” has an archaic meaning: “tests the rule”.

The point is that handling the host unreachable is almost always semantically higher level than the code opening the connection. This the code opening doesn’t implement the policy of what to do when the situation occurs. In the case, say, of a hard-coded address then it’s possible the author of that piece of code does know how to handle a host unreachable case.

[talaketu]

Yes, this is said, but the meaning of "prove" (which is related to "probe") has not really changed very much at all compared to "test" - a word which in this sense is a metonym from the fired pot used for assay of metal. The meaning in "mathematical proof" or "prove beyond reasonable doubt" or "prove your love" doesn't really diverge significantly from this so-called archaic meaning - a demonstration to show.

On the software abstraction, exceptions are simply a convenient implicit control flow device for handling the alternate path when an intended state cannot be achieved. I don't follow the paper's argument that "current exception design is suboptimal for efficient implementation" - but I would not be surprised considering the lifetime issues.

[gumby]

> I don't follow the paper's argument that "current exception design is suboptimal for efficient implementation"…

The argument of the paper is really that exception handling shouldn’t use a global lock, a problem made worse by the proliferation of processor cores on modern chips.