3 ms·
It's less about bad habits and more about there being a clear and consistent signal for what can throw or not. It's similar to why I like options over nulls de
by reificator 7y ago
It's less about bad habits and more about there being a clear and consistent signal for what can throw or not. It's similar to why I like options over nulls despite the fact that you're basically doing the same thing in both systems.
If only Java's particular implementation hadn't ruined the public opinion on checked exceptions...
- kjeetgill 7y agoWhat do you think is the best way to handle checked exceptions? This comes up all the time on HN and I've personally landed on preferring Java's checked/unchecked system from anything else I've seen. I get that sometimes you should handle your errors in the small, like Go's errors or Rust's Maybe (or Try?) styles might prefer, but I hate not having any exceptions options to "let things crash".
- reificator 7y agoRust's Result<T, E> and similar options in other languages are by far my favorite, especially with the `?` operator and pattern matching to go along with them. Rust and golang do both also contain a `panic` that allows you to just "let things crash". But by being separate from the standard methods of error handling, they tend to be used in actual exceptional circumstances. I'm not a fan of exceptions in general, but a system that had exclusively checked exceptions, but didn't require such verbosity would be nice. Perhaps an annotation that says a method can throw, and any method without that annotation cannot throw?