Checked exceptions are powerful but misunderstood. Exception types are a useful part of the facade to a module - they express to a caller how it can go wrong even if used correctly.

Runtime exceptions are typically there to express contract-breaking by callers; although as an alternative return mechanism I've seen them used to simplify the inner workings of some frameworks.

I think they get a bad rep because there aren't a ton of good examples of how to use them - even the java classpath had some egregious misuse initially that helped turn people off the key ideas.

[–] magic_lobster_party@kbin.run 5 points 3 months ago (10 children)

Imo, if a method require the caller to do error handling, then that should be part of the return value. For example, use optional or either. Exceptions shouldn’t be part of any expected control flow (like file not found). Exceptions is an emergency panic button.

[–] state_electrician@discuss.tchncs.de 2 points 3 months ago (2 children)

The exception is part of the method signature and thus part of the return value. I don't see a difference between using if or try-catch to validate a method call.

[–] magic_lobster_party@kbin.run 1 points 3 months ago (1 children)

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.

[–] state_electrician@discuss.tchncs.de 1 points 3 months ago

How is that different than what Go, for example, does? An if err != nil after each statement is just as annoying. In the end you have to validate almost all return values and the way it happens is just syntax.

load more comments (7 replies)