I’m not sure why it’s “obviously” good to move from one mechanism to two: as a user I now have to categorise every path to work out which is appropriate.

What I said was less about adding to a function signature than it was about adding to a facade - that is, a system boundary, although the implementation may be the same depending on language. People typically use exceptions pretty badly - a function signature with a baggage-train of internal exceptions that might be thrown by implementation guts is another antipattern that gives the approach a bad rep. Errors have types too (or they should have), and the typical exception constructor has a wrapper capability for good reason.

I think try catch often leads to messy code. It breaks the control flow in weird ways. For some reason we’ve collectively agreed on that goto is a bad idea, but we’re still using exceptions for error handling.

Consider this example:

try {
    File file = openFile();
    String contents = file.read();
    file.close();
    return contents:
} catch (IoException) {
}

Say an exception is triggered. Which of these lines triggered the exception? It’s hard to tell.

We might want to handle each type of error differently. If we fail to open the file, we might want to use a backup file instead. If we fail to read the file, we might want to close it and retry with the same file again to see if it works better this time. If we fail to close the file, we might just want to raise a warning. We already got what we wanted.

One way to handle this is to wrap each line around a separate try catch. This is incredibly messy and leads to problematic scopes. Another way is to have 3 different exception types: FileOpenException, FileReadException and FileCloseException. This is also incredibly messy.

Or we can include the error in the return value. Then we can do whatever we want programmatically like any other code we write.