3 ms·

Optional is okay. Of course, you could still be a real jerk and return null instead of Optional<T> and the compiler won't warn me at all and I'll just get an NP

Optional is okay. Of course, you could still be a real jerk and return null instead of Optional<T> and the compiler won't warn me at all and I'll just get an NPE at run time... But it probably won't happen. The problem with Try/Result is that you still have to do manually unwrapping and/or early returns. Scala and Haskell have monad comprehensive to make this less noisy. Rust has the ? operator. Java has nothing. This makes your code WAY more noisy than having a try-catch inside your non-trivial function. In a proper world, callers should NOT be aware of all exceptions a function can throw. That's exactly the point of having checked and unchecked exceptions. Checked means the library author thought there is a chance that you might want to handle the exception locally. Unchecked means the library author does not want you to try to recover- they've already determined you're screwed.

sreque 6y ago
I don't think this is true in theory or in practice. Java's Integer.valueOf(String) throws an unchecked exception if it fails, and you should very much be aware of it and catch it in many situations. Also, in many situations, it doesn't make sense to catch IOException but rather let it propagate. The set of exceptions you should not be expected to catch is generally a very narrow subset of unchecked exceptions, like java.lang.LinkageError or NPE due to internal bug in the called method.
- ragnese 6y ago
  Ack. Totally agree about Integer.valueOf. I think I agree about IOException, too. Definitely most other people agree that it should've been unchecked and that does seem reasonable, as long as it's really only thrown for "oh shit- someone unplugged the hard drive" errors. I still think that in theory, the distinction I articulated would be proper. I'd always prefer returning algebraic data types rather than checked exceptions if I were inventing a new language. But given that Java has nothing in the way of that, I'd still say that one should attempt to follow the hypothetical distinction I articulated, even if Java itself fails at it...

sreque 6y ago

I don't think this is true in theory or in practice. Java's Integer.valueOf(String) throws an unchecked exception if it fails, and you should very much be aware of it and catch it in many situations. Also, in many situations, it doesn't make sense to catch IOException but rather let it propagate. The set of exceptions you should not be expected to catch is generally a very narrow subset of unchecked exceptions, like java.lang.LinkageError or NPE due to internal bug in the called method.

ragnese 6y ago
Ack. Totally agree about Integer.valueOf. I think I agree about IOException, too. Definitely most other people agree that it should've been unchecked and that does seem reasonable, as long as it's really only thrown for "oh shit- someone unplugged the hard drive" errors. I still think that in theory, the distinction I articulated would be proper. I'd always prefer returning algebraic data types rather than checked exceptions if I were inventing a new language. But given that Java has nothing in the way of that, I'd still say that one should attempt to follow the hypothetical distinction I articulated, even if Java itself fails at it...