7 ms·

> The biggest argument against “checked” exceptions is that most exceptions can’t be fixed. The simple fact is, we don’t own the code/ subsystem that broke. We

by aazaa 6y ago

> The biggest argument against “checked” exceptions is that most exceptions can’t be fixed. The simple fact is, we don’t own the code/ subsystem that broke. We can’t see the implementation, we’re not responsible for it, and can’t fix it. Here's what Oracle has to say: > Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception. https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html https://docs.oracle.com/javase/tutorial/essential/exceptions... - checked exception for recoverable errors - unchecked exception for non-recoverable errors So the argument that most errors can't be recovered from is _not_ a reason to abandon checked exceptions. It's a reason to reserve checked exceptions for those cases in which recovery is likely. The main argument in this article appears to be based on a misunderstanding.

tootie 6y ago
The argument is that an error that can be recovered from isn't an exception. It should handled with standard guards (bounds check, null check, format check, etc). There's no checked exception that can't be better solved with an if/then statement.
- nordsieck 6y ago
  > The argument is that an error that can be recovered from isn't an exception. It should handled with standard guards (bounds check, null check, format check, etc). There's no checked exception that can't be better solved with an if/then statement. That's a philosophical position that is largely driven by the language (and I suppose the ecosystem around it). I happen to agree with that position, so I prefer languages like rust and go over java. But I also know that if I try to fight the customs of the language I'm working in, it'll end in a lot of pain and unnecessary angst; so, if I find myself using Java, I grit my teeth and used checked exceptions.
  - tootie 6y ago
    Checked exceptions are optional in Java. If you look at a even an long-standing enterprise platform like Spring, there's almost no checked exceptions. I always make it a policy on Java projects to not allow checked exceptions and it's never a problem. Anything in the standard lib may have to be dealt with, but I don't allow commits with any throws declaration.
- srtjstjsj 6y ago
  Why should all the callers have to redundantly implement all the validity checks instead of implementing them once in the callee and reporting the result?
  - tootie 6y ago
    The callee should not return invalid results. It can return empty data or some kind of results wrapper or just throw a runtime exception of something really catastrophic happened.
zmmmmm 6y ago
It's interesting that is how it is described, as it is at odds with actual usage. From my memory going back to early 2000's, it was seen as bad form to use an unchecked exception in "user land" code - these were looked at as only for very severe internal failures like out of memory or similar. This was probably encouraged by IDEs that will auto-generate code for you for handling, rethrowing, adding to type signatures etc etc that proliferate the exceptions up through API layers. But it also seems at odds with the language itself ... for example a simple file not found will generate a checked IOException out of the standard libraries. It seems strange to suggest there is recovery from that (beyond choosing another file). Even though I completely agree that checked exceptions make Java a huge pain to work with, I do feel something has been lost when I use languages that don't support them or any alternatives. Having no way to enforce systematic handling of an error isn't a great solution either.
- Nursie 6y ago
  > It seems strange to suggest there is recovery from that (beyond choosing another file). That's the thing though, right? If you're writing a program with a UI you want to pop up a box saying "File not found, choose another". A server program might format an appropriate response, log it and send it back to the client. A batch process may just want to bail with a code. So it would seem to make sense to have it checked...
jcelerier 6y ago
> Here's what Oracle has to say: doing the opposite of what Oracle has to say seems a good guideline in life
lliamander 6y ago
Checked exceptions are the poor man's sum types. They're overly ceremonious for relatively limited functionality (don't encompass the broad range of circumstances where you would want to have multiple return types) and poor composability (e.g. lamdas).
ratherbefuddled 6y ago
Misuse of checked exceptions pre-dates this advice and some of those libraries are very slow to go away. Library and framework developers mostly only know that a client cannot recover from an exception; rarely can they make good judgement about when a client can recover from one but they have to bake that choice in. It's more flexible to encode error or otherwise abnormal returns into the return type - there is basically no reason to prefer a checked exception.
jtolmar 6y ago
That guideline ends up less great than it sounds, in practice, since the kind of error a client can recover from is very client-sensitive. A general-use library, like Java's, needs to throw checked exceptions for anything that /any/ caller could reasonably catch. If you're writing, say, a file converter, then there's nothing you can reasonably do about an IOException. But plenty of other programs can show an error dialog and keep moving. There's usually going to be some sort of exception that's completely out of scope for you. As unfortunate as that is though, I don't really think it's something that can be done better. Ultimately errors are breaks in a function's abstraction. There's nothing that a readFile() function can do about a missing file, because it doesn't know how that file was selected or what you're going to use it for. The only way around the error would be absurdly coarse abstractions like readUserSelectedFileInGuiProgram() and readCriticalFilePackedWithProgram(). Better syntax can reduce the boilerplate - algebraic types plus match expressions are certainly an improvement. But the guidelines for when you should return one end up the same as the guidelines for a checked exception, since they're expressions of the same idea.
mumblemumble 6y ago
> If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception. Trying to make those decisions as a library author is a sort of combination of the tail wagging the dog and self-fulfilling prophecies. Depending on the client's ethos and operating parameters, they may or may not reasonably want to try to recover from anything. Java's designers decided that failing to reserve memory for a new heap allocation isn't something that people might want to recover from, and so it really is impractical to do so - for lack of documentation as much as for any technical reason. On the other hand, Zig decided that developers should be able to recover from it, and so it's really not such a big deal for Zig developers. Personal example: I tend to be a "let it crash" person, so I generally write code that throws exceptions that really are hard to handle. Not because of any fundamental reason, just because that attitude leads me to be a bit more loosey goosey about organizing and documenting the exceptions that I throw. I get away with it because it's all internal projects. If I were writing an open source library meant for public consumption, I'd probably try to be more disciplined, so that users could choose their own moral paradigm.
vbezhenar 6y ago
As a library writer, almost always you can’t decide whether your user can recover or not. So checked exceptions for libraries would be used very rarely. They might be useful for application code. But they were abused for Java standard library and now most people hate them. At this point I would rather see them gone. If I would want to force API user to handle result, probably I would just use something like Optional.
- srtjstjsj 6y ago
  People hate them because they want to quickly write unreliable software but are using a language designed for building reliable software
  - vbezhenar 6y ago
    Java is positioned and used as a general-purpose programming language. I don't think that it was specifically designed for building etra-reliable software.

by aazaa 6y ago

tootie 6y ago

The argument is that an error that can be recovered from isn't an exception. It should handled with standard guards (bounds check, null check, format check, etc). There's no checked exception that can't be better solved with an if/then statement.

nordsieck 6y ago
> The argument is that an error that can be recovered from isn't an exception. It should handled with standard guards (bounds check, null check, format check, etc). There's no checked exception that can't be better solved with an if/then statement. That's a philosophical position that is largely driven by the language (and I suppose the ecosystem around it). I happen to agree with that position, so I prefer languages like rust and go over java. But I also know that if I try to fight the customs of the language I'm working in, it'll end in a lot of pain and unnecessary angst; so, if I find myself using Java, I grit my teeth and used checked exceptions.
- tootie 6y ago
  Checked exceptions are optional in Java. If you look at a even an long-standing enterprise platform like Spring, there's almost no checked exceptions. I always make it a policy on Java projects to not allow checked exceptions and it's never a problem. Anything in the standard lib may have to be dealt with, but I don't allow commits with any throws declaration.
srtjstjsj 6y ago
Why should all the callers have to redundantly implement all the validity checks instead of implementing them once in the callee and reporting the result?
- tootie 6y ago
  The callee should not return invalid results. It can return empty data or some kind of results wrapper or just throw a runtime exception of something really catastrophic happened.

zmmmmm 6y ago

It's interesting that is how it is described, as it is at odds with actual usage. From my memory going back to early 2000's, it was seen as bad form to use an unchecked exception in "user land" code - these were looked at as only for very severe internal failures like out of memory or similar. This was probably encouraged by IDEs that will auto-generate code for you for handling, rethrowing, adding to type signatures etc etc that proliferate the exceptions up through API layers. But it also seems at odds with the language itself ... for example a simple file not found will generate a checked IOException out of the standard libraries. It seems strange to suggest there is recovery from that (beyond choosing another file). Even though I completely agree that checked exceptions make Java a huge pain to work with, I do feel something has been lost when I use languages that don't support them or any alternatives. Having no way to enforce systematic handling of an error isn't a great solution either.

Nursie 6y ago
> It seems strange to suggest there is recovery from that (beyond choosing another file). That's the thing though, right? If you're writing a program with a UI you want to pop up a box saying "File not found, choose another". A server program might format an appropriate response, log it and send it back to the client. A batch process may just want to bail with a code. So it would seem to make sense to have it checked...

jcelerier 6y ago

> Here's what Oracle has to say: doing the opposite of what Oracle has to say seems a good guideline in life

lliamander 6y ago

Checked exceptions are the poor man's sum types. They're overly ceremonious for relatively limited functionality (don't encompass the broad range of circumstances where you would want to have multiple return types) and poor composability (e.g. lamdas).

ratherbefuddled 6y ago

Misuse of checked exceptions pre-dates this advice and some of those libraries are very slow to go away. Library and framework developers mostly only know that a client cannot recover from an exception; rarely can they make good judgement about when a client can recover from one but they have to bake that choice in. It's more flexible to encode error or otherwise abnormal returns into the return type - there is basically no reason to prefer a checked exception.

jtolmar 6y ago

That guideline ends up less great than it sounds, in practice, since the kind of error a client can recover from is very client-sensitive. A general-use library, like Java's, needs to throw checked exceptions for anything that /any/ caller could reasonably catch. If you're writing, say, a file converter, then there's nothing you can reasonably do about an IOException. But plenty of other programs can show an error dialog and keep moving. There's usually going to be some sort of exception that's completely out of scope for you. As unfortunate as that is though, I don't really think it's something that can be done better. Ultimately errors are breaks in a function's abstraction. There's nothing that a readFile() function can do about a missing file, because it doesn't know how that file was selected or what you're going to use it for. The only way around the error would be absurdly coarse abstractions like readUserSelectedFileInGuiProgram() and readCriticalFilePackedWithProgram(). Better syntax can reduce the boilerplate - algebraic types plus match expressions are certainly an improvement. But the guidelines for when you should return one end up the same as the guidelines for a checked exception, since they're expressions of the same idea.

mumblemumble 6y ago

> If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception. Trying to make those decisions as a library author is a sort of combination of the tail wagging the dog and self-fulfilling prophecies. Depending on the client's ethos and operating parameters, they may or may not reasonably want to try to recover from anything. Java's designers decided that failing to reserve memory for a new heap allocation isn't something that people might want to recover from, and so it really is impractical to do so - for lack of documentation as much as for any technical reason. On the other hand, Zig decided that developers should be able to recover from it, and so it's really not such a big deal for Zig developers. Personal example: I tend to be a "let it crash" person, so I generally write code that throws exceptions that really are hard to handle. Not because of any fundamental reason, just because that attitude leads me to be a bit more loosey goosey about organizing and documenting the exceptions that I throw. I get away with it because it's all internal projects. If I were writing an open source library meant for public consumption, I'd probably try to be more disciplined, so that users could choose their own moral paradigm.

vbezhenar 6y ago

As a library writer, almost always you can’t decide whether your user can recover or not. So checked exceptions for libraries would be used very rarely. They might be useful for application code. But they were abused for Java standard library and now most people hate them. At this point I would rather see them gone. If I would want to force API user to handle result, probably I would just use something like Optional.

srtjstjsj 6y ago
People hate them because they want to quickly write unreliable software but are using a language designed for building reliable software
- vbezhenar 6y ago
  Java is positioned and used as a general-purpose programming language. I don't think that it was specifically designed for building etra-reliable software.