3 ms·
You and I clearly have different error handling strategies. I will say that a rust-style error propagation operator would cut verbosity even further. (Though t
by reificator 7y ago
You and I clearly have different error handling strategies.
I will say that a rust-style error propagation operator would cut verbosity even further. (Though that is harder to do in go with their choice of multiple return over sum types.)
Still, try/catch seems far more verbose for common error handling strategies to me. And I'd rather see an acknowledgement that something can fail as close to that thing as possible, rather than hunting thorough the stack to find some global try/catch block that silently swallows the error in order to cut down on verbosity.
- spullara 7y agoI'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?