3 ms·
Whew, this is a hairy topic. The go camp has the same conversation around returning error codes. I think checked exceptions are clunky, irritating, but all-in-
by kjeetgill 8y ago
Whew, this is a hairy topic. The go camp has the same conversation around returning error codes.
I think checked exceptions are clunky, irritating, but all-in-all fairly good solution. I'd rather be forced to check an exception than to bit know about it at the very least.
I think Java's situation could be improved with 2 very minor changes if we had a time machine.
1) Make throwing any exception an unchecked "RuntimeException". The point is just to remove the type-based duality. Functions that declare "throws" still need to be checked.
2) A cleaner syntax to rethrow "try { } rethrow;" maybe. This won't force your function to declare anything. That's always a personal choice.
These could address the core issues, but still require a little education around best practices. If I had to distill them I'd put it this way:
There's no shame in just rethrowing unchecked through the layers of your own code unchecked or crashing a thread or request if you planned it, BUT if an exception is leaving "your code" and called by "someone else" make it checked. Preferably use an appropriate type.
Example: I'm writing an encoding library on top of an HDFS client. My functions should declare FileNotFound or IOException even though the came from the client "below" me because I want to be a good citizen to the code "above" me. Internally, my code doesn't need 10 thousand checked functions though.
- groestl 8y agoI absolutely loathe whenever I come across an IOException. I _know_ that something can go wrong, everything will go wrong at some point, so my code needs to crash appropriately, everywhere. Nobody has to tell me about that, so no need for IOException or a MyLibraryException checked exception subtree. There are a few specific cases where I might recover, and it's absolutely okay to check the documentation for them.
- kjeetgill 8y agoWhat? Do you think it's the libraries job to decide that the program should crash or yours? I assume you agree that they should at least declare that they throw them? I agree that the rethrow should be painless at least.
- groestl 8y agoI'm not sure I follow the first paragraph, but what I'm trying to say is that the JVM can, at any point, present an unchecked exception, or an error. In that case, at the very least, all resources have to be released, and nothing should possibly be left in an invalid state. All this while the stack is unwinding. It's unnecessary to communicate that some call might fail. It's even misleading: a novice might handle a checked exception and rollback some state, but not think of all the implicit exceptions that might occur, e.g. a stack overflow. I'm not even talking about subsystems being replaced by distributed versions (so now there are networking errors too) or similar issues arising from composability. So resource allocation and state logic should be written in a way that assumes everything can crash and burn at any time. And then one can sprinkle recovery and retry logic on top of it, but only in very specific cases, and on specific layers of the application.