4 ms·
I'd rather have the choice to handle it locally or not. If you have bad habits you have bad habits and another language isn't going to fix that. If Go adapts Ru
by spullara 7y ago
I'd rather have the choice to handle it locally or not. If you have bad habits you have bad habits and another language isn't going to fix that. If Go adapts Rust style then I would agree, it could get to be where you can choose to handle the errors locally or up the stack, like exceptions, and you will be in a better place.
- reificator 7y agoIt'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?