The problem is that when exceptions are available, people will start using them for non-exceptional things and (the worst case) basic control flow.
Case in point from a popular framework, Django: the standard way of getting an object from the DB via the ORM is Class.objects.get. This method either returns a single object or raises on exception if there are zero rows in the db or another exception if there are two or more rows. It may also raise other kinds of exceptions.
Now, it's clear that having zero rows is not very exceptional, and even >1 is somewhat debatable. Note especially that this is not just some weekend project by a nobody, it is a framework that is widely used and respected.
Except that get accepts as parameters non-unique non-primary fields too.
I have every reason to believe that the Django devs are capable people who thought about this and landed on this specific usage with a clear rationale... but it still is a misuse of error handling capabilities of a language. And a sort of misuse that everyone else does sometimes as well.
I agree with your first paragraph but not with the Django example. User.objects.get(id=1) failing is exceptional because you are asking for an object with a specific and unique property. Otherwise, you would be using User.objects.filter(age>20) (which doesn't throw an exception).
I might kinda agree that exact queries against primary keys not having results (or having more than 1) would be exceptional, but this actually happens for every other field as well.
Sometimes you want non-local transfers of control, beyond just exceptions. Python uses exceptions as both error conditions and signals.
It's seemingly nearly mandatory in discussions regarding exceptions to bring up Common Lisps's condition system, which is a superset of exceptions. I've included a link to a chapter from a book on Lisp.
that's not a Django problem; it's a Python problem. Using exceptions for control flow is idiomatic in Python. Case in point: a generator is supposed to raise a StopIteration exception in order to signal termination.
Go has no exceptions. Instead, functions can return multiple values, one of which is an error, and you check the error value on invocation. It's tedious and awful and makes your code very ugly and it's absolutely correct and I love it. It takes some getting used to, but once you do it for a while, you realize that exception handling systems are broken and unnecessary. E.g.:
func MaybeAnInt() (int, error) {
if FAIL {
return 0, errors.New("this is the error message")
}
return 42, nil
}
x, err := MaybeAnInt()
if err != nil {
// handle your error
}
// normal shit here.
If you would think a bit more broadly, you might also see this so that all the error handling code is visible, explicit and right there with the actual logic, and not hidden away what might be (and often is) multiple layers of modules.
it sounds bad in theory, but in practice it turns out to be quite good. It's actually the opposite; because you know that there's no exceptions, control flow is very obvious. Whether a function does or does not return an error is a part of its signature. You always know, when calling a function, if it may or may not return an error, and it is up to the caller to decide what to do with that error. As a result, there's no control flow pitfalls like forgetting to close a filehandle because an exception was thrown in some function that you didn't know could throw an exception.
that does not scale. you can have hundreds of calls that require error handling inside your code. considering your example you would get the section "//handle you error" hundreds of times. sprinkled all over the place.
