5 ms·

Java's checked exceptions were a disaster. It essentially handcuffed you, limiting what you could do in an overridden method (because you can't add more excepti

Java's checked exceptions were a disaster. It essentially handcuffed you, limiting what you could do in an overridden method (because you can't add more exceptions to the throws list). So you end up wrapping in RuntimeExceptions and then later having the whole app fall over because the framework that's expecting your class was only designed to handle the checked exceptions. So yeah, want your implementation to consult a database? Sorry, the interface you must implement doesn't declare any checked exceptions, so say hello to app-killing RuntimeException wrapped SQLExceptions :/

specialist 10y ago
Checked exceptions are the correct answer. Just handle it. Exception obfuscation frameworks (Spring) just kick the can down the road, creating problems without any discernible benefit.
skybrian 10y ago
Checked exceptions probably would have been fine if there were only one kind of checked exception. Most methods would declare it and they'd all be compatible. This would be similar to how Go functions always return the same error type, but without the boilerplate.
- bshanks 10y ago
  But wouldn't that kind of defeat the point? Sort of like how having a type system with only one type wouldn't be very helpful.
concede_pluto 10y ago
> interface you must implement doesn't declare any checked exceptions It verges on malpractice to design an interface and declare that no implementation of it could possibly ever fail. I'm looking at you, Runnable.
scott_s 10y ago
I ran into this when writing an ANTLR parser. I wanted to throw specialized exceptions based on what went wrong in the parse, but these couldn't be checked exceptions for the above reason. So I had to derive them from RuntimeException, and then I wrapped the call to the parser so that it caught just this kind of exception, and re-threw it as a non-RuntimeException so that it was checked throughout the rest of the code. I think this is an ANTLR-idiom, which I found to be an odd quirk - but one that's unavoidable because of how ANTLR and Java are designed.

specialist 10y ago

Checked exceptions are the correct answer. Just handle it. Exception obfuscation frameworks (Spring) just kick the can down the road, creating problems without any discernible benefit.

skybrian 10y ago

Checked exceptions probably would have been fine if there were only one kind of checked exception. Most methods would declare it and they'd all be compatible. This would be similar to how Go functions always return the same error type, but without the boilerplate.

bshanks 10y ago
But wouldn't that kind of defeat the point? Sort of like how having a type system with only one type wouldn't be very helpful.

concede_pluto 10y ago

> interface you must implement doesn't declare any checked exceptions It verges on malpractice to design an interface and declare that no implementation of it could possibly ever fail. I'm looking at you, Runnable.

scott_s 10y ago

I ran into this when writing an ANTLR parser. I wanted to throw specialized exceptions based on what went wrong in the parse, but these couldn't be checked exceptions for the above reason. So I had to derive them from RuntimeException, and then I wrapped the call to the parser so that it caught just this kind of exception, and re-threw it as a non-RuntimeException so that it was checked throughout the rest of the code. I think this is an ANTLR-idiom, which I found to be an odd quirk - but one that's unavoidable because of how ANTLR and Java are designed.