And I’d completely agree with that.

You’re quite right: This is hardly a new point (I’m slightly surprised I didn’t mention this). There are a bunch of languages which already do it. OCaml and, to a lesser extent, Haskell also do.

As far as the exceptional circumstances thing goes: I’d say that it’s meaningless as an argument regardless of whether it’s meaningful as a statement, because as your example shows there’s a lot of wiggle room in what you consider to be exceptional.

One of these is Python, which mainly does it at two levels:

* Python’s Iterator protocol is made of two methods __iter__ and next(), __iter__ returns the iterator and next() returns the next item in the iterator. You’ll notice there is no has_next() method, and that’s because when calling next() on an expanded iterator, the iterator simply throws StopIteration.

* Error handling/condition checking (or the lack thereof). The Python community broadly subscribes to the EAFP principle: it’s easier to ask for forgiveness than permission, so if you want something just do it and if things break clean up.

One of the classic example of this is fetching a value (which may or may not be there) from a map. Java code will pretty much always take the form

if(map.containsKey(someKey)) {
T value = map.get(someKey);
} else {
// stuff to do if someKey wasn’t in the map
}

while Python code, though it will be found in this form as well (tends to vary based on the number of misses expected, mostly) will very often read:

try:
value = my_dict[some_key]
except KeyError:
# stuff to do if some_key isn’t in my_dict

And as an aside, that doesn’t mean “Exceptions are for exceptional situations” is meaningless, the issue here is what people consider “exceptional circumstances”. I tend to like Python’s approach of “yeah when you’re iterating having a next item is normal. Not having one is exceptional”.

Under the “Exceptions are Slow” heading you say

The JVM too (with some mild tricks) has very fast exceptions.

The parenthetical comment, “with some mild tricks”, links to a very critical caveat – Java exceptions are much faster:

IF you write custom exception classes
IF you explicitly disable stack trace generation in your custom classes
IF you exclusively use custom exception classes for control flow

In contrast, Exceptions that were designed for error handling do generate stack traces. I have found more then a few examples of code implementing control flow using exceptions designed for error handling.

A better title for your post would be:

“Custom exceptions for control flow considered perfectly acceptable, thanks very much”

The new initial word is key.

A final observation – you argue that the phrase “Exceptions are for exceptional situations” is meaningless. The phrase may sacrifice strict accuracy for catchiness, and there are certainly ambiguous cases. But in day-to-day programming, I don’t spend time anguishing over whether a condition is an exception condition or a control flow condition. The distinction between the two is clear; I handle control flow the old-fashioned way and throw exceptions for errors.