4 ms·

> - if you have enough context to handle the error (eg. retry, or degrade gracefully, or perform whatever other application logic to recover, possibly returning

by xienze 7y ago

> - if you have enough context to handle the error (eg. retry, or degrade gracefully, or perform whatever other application logic to recover, possibly returning a more friendly error to your caller), do that, possibly logging the source error and do not return it further up the stack directly - you have now healed the error condition, and the application code can continue. > - otherwise, return the error, decorating it with extra context if possible. This is precisely how checked exception handling works in Java, and yet there's no shortage of people complaining about it and praising how Go "makes you deal with it the way you're supposed to." > it forces you to _think_ about error cases and at least reminds you to handle them gracefully. So do checked exceptions. And 99% of the time, the solution to an error popping up in Java is to blindly re-throw it because hey, I'm just a component buried a couple levels deep in a REST call, what could I possibly do to fix the problem?

badsectoracula 7y ago
Interestingly you bring checked exceptions, i used to dislike them at the past but in recent years i came to appreciate having a visible flow of execution (and as such i prefer the C approach of explicit returns - note that i haven't used Go at all, i'm just curious about it) which made me think that Java forcing you to acknowledge any exception that may pass through and actively make a decision about it (handle it or explicitly pass it through) is a good thing. Though it also made me dislike its decision for runtime exceptions since they essentially bypass the checking (on the other hand they'd somehow had to handle things like NullPointerException, otherwise everything would need to declare that it would throw it - though perhaps that is a side effect of Java having nullable pointers and a different language without nullable pointers wouldn't need that... but that'd only fix the NullPointerException case).
klodolph 7y ago
Error handling is hard. Checked exceptions and Go’s error returns are both good attempts to solve it. They both have plenty of drawbacks but they’re really different approaches here. > This is precisely how checked exception handling works in Java, and yet there's no shortage of people complaining about it and praising how Go "makes you deal with it the way you're supposed to." Just because people complain about Java’s checked exceptions does’t mean that their complaints are correct or that they somehow apply to Go’s errors. The main complaints I hear about checked exceptions are that they force you to expose the types of all possible exceptions in the method signature. This creates unexpected API churn and design difficulties, because it’s difficult to predict which exception types you would want to expose from a particular interface. You also have to choose which errors are programming errors and which are not when you declare the error type. This turned out to cause problems. NumberFormatException is an example. > So do checked exceptions. And 99% of the time, the solution to an error popping up in Java is to blindly re-throw it because hey, I'm just a component buried a couple levels deep in a REST call, what could I possibly do to fix the problem? In Go, blindly returning an error is done much less than 99% of the time, at least in the code bases I’ve worked on or read.
wst_ 7y ago
I really like how Rust authors did it. If you don't need to add additional context, you can use `?` after the expression that may return error and if it does, it automatically returns it. No need for endless `if err != nil` and effect is the same. It makes code base really clean and easy to work with.

by xienze 7y ago

badsectoracula 7y ago

Interestingly you bring checked exceptions, i used to dislike them at the past but in recent years i came to appreciate having a visible flow of execution (and as such i prefer the C approach of explicit returns - note that i haven't used Go at all, i'm just curious about it) which made me think that Java forcing you to acknowledge any exception that may pass through and actively make a decision about it (handle it or explicitly pass it through) is a good thing. Though it also made me dislike its decision for runtime exceptions since they essentially bypass the checking (on the other hand they'd somehow had to handle things like NullPointerException, otherwise everything would need to declare that it would throw it - though perhaps that is a side effect of Java having nullable pointers and a different language without nullable pointers wouldn't need that... but that'd only fix the NullPointerException case).

klodolph 7y ago

Error handling is hard. Checked exceptions and Go’s error returns are both good attempts to solve it. They both have plenty of drawbacks but they’re really different approaches here. > This is precisely how checked exception handling works in Java, and yet there's no shortage of people complaining about it and praising how Go "makes you deal with it the way you're supposed to." Just because people complain about Java’s checked exceptions does’t mean that their complaints are correct or that they somehow apply to Go’s errors. The main complaints I hear about checked exceptions are that they force you to expose the types of all possible exceptions in the method signature. This creates unexpected API churn and design difficulties, because it’s difficult to predict which exception types you would want to expose from a particular interface. You also have to choose which errors are programming errors and which are not when you declare the error type. This turned out to cause problems. NumberFormatException is an example. > So do checked exceptions. And 99% of the time, the solution to an error popping up in Java is to blindly re-throw it because hey, I'm just a component buried a couple levels deep in a REST call, what could I possibly do to fix the problem? In Go, blindly returning an error is done much less than 99% of the time, at least in the code bases I’ve worked on or read.

wst_ 7y ago

I really like how Rust authors did it. If you don't need to add additional context, you can use `?` after the expression that may return error and if it does, it automatically returns it. No need for endless `if err != nil` and effect is the same. It makes code base really clean and easy to work with.