5 ms·

Explicit error recovery is not hell, it's a blessing. Much easier to understand and to maintain than exception handling.

by vardump 12y ago

tomjakubowski 12y ago
There is a third way. See Haskell's Either l r, or Rust's Result<T, E> types. See http://lucumr.pocoo.org/2014/10/16/on-error-handling/ http://lucumr.pocoo.org/2014/10/16/on-error-handling/ and http://lucumr.pocoo.org/2014/11/6/error-handling-in-rust/ http://lucumr.pocoo.org/2014/11/6/error-handling-in-rust/ I don't know why so often, the immediate reaction to legitimate criticism of this wart in Go is to argue against exceptions, even when nobody has even brought up exceptions as an alternative.
- thirsteh 12y ago
  In fact, Either/Maybe can function like safer versions of both paradigms: Functors allow you to build a program of many functions that will terminate with 'Nothing' or 'Either l' as long as any one of them experiences an error, without thinking about errors, and it still lets you explicitly handle any errors if you want to, this time on the sum type Maybe or Either, meaning that you usually handle both the error and non-error case, or receive a compiler warning. I agree that, probably universally, the people who fervently argue for either exceptions or explicit Go-style error handling don't know about Maybe/Either/Result. Then again, all this is pretty much impossible to replicate in Go.
- vezzy-fnord 12y ago
  Option types are nice. The fourth way (and I think the best) is supervision trees, though this is more applicable when you have multiple units of execution... which Go does, so not having something similar out of the box seems strange. That said, even something as simple as errors being literal values that you can pattern match on is surprisingly versatile. Exceptions don't necessarily have to be awful weights that spill down all over the call stack, either. They can be distilled to a more basic catch/throw mechanism for shuffling around error properties and states.
  - threeseed 12y ago
    Personally I love option types but working on a large Scala project at the moment it sometimes results in non ideal behaviour from developers especially those coming from the Java world. What I've seen a lot of is swallowing of errors. For example readFromFile().orElse("") where there is no indication from an outsider that anything wrong happened. A cool feature would be logging any instance of when orElse was the result. Would be curious how these work in other languages.
    - Jweb_Guru 12y ago
      The trick is to make it very ergonomic to return the error. I thought Scala had do notation to make this the case. In Rust, the try! macro (which returns on error) is shorter than almost any other way to handle an error, so people usually use that.
- Dewie2 12y ago
  Thank you for mentioning this. It's frustrating that every time someone complains about Go's error-handling style, the first assumption is that the complainer then necessarily has to prefer exceptions. In truth, errors-as-values are very elegant in languages like Haskell IMO. And errors-as-values are not at all something that Go has managed to put back on the roadmap in a modern language against the grain of everyone else (the "exception people") as many seem to imply, including Rob Pike in his "errors as values" article.
threeseed 12y ago
I'm confused what makes exception handling so troublesome ? Personally I find them essential in particular for larger codebases. They allow for centralised, consistent error handling behaviour. For example paging application support teams only for certain types of errors. And you can always emulate explicit error recovery with exceptions. So what is so bad about having the flexibilty to accomodate different styles of error handling.
- xienze 12y ago
  Yeah, I don't understand the objection to exceptions either. I _think_ the reason is because people treat them much the same was as errors in C/Go/etc., i.e., "I have to catch them here and recover right away." If you're doing it that way, you're doing it wrong. Design the system such that exceptions can be rethrown (bubbled up) and defer the handling as long as possible.
- mike_hearn 12y ago
  Nothing. This is one of those "Go doesn't have it, so it must be bad" things. The way Go handles errors is a throwback to C and was abandoned by literally every single imperative language for good reasons.
4ydx 12y ago
Honestly I wish that golang forced you to acknowledge all return values from methods even if you simply ignore them ( _ = Method() ). When I read the docs for any method calls in golang I like being able to see that something returns an error just by looking at the function signature. Certainly I might not know how to handle all the error variations, but not having to decide if I need to wrap something in try/catch... I dunno it just resonates with me.

Explicit error recovery is not hell, it's a blessing. Much easier to understand and to maintain than exception handling.

by vardump 12y ago

Explicit error recovery is not hell, it's a blessing. Much easier to understand and to maintain than exception handling.

tomjakubowski 12y ago

There is a third way. See Haskell's Either l r, or Rust's Result<T, E> types. See http://lucumr.pocoo.org/2014/10/16/on-error-handling/ http://lucumr.pocoo.org/2014/10/16/on-error-handling/ and http://lucumr.pocoo.org/2014/11/6/error-handling-in-rust/ http://lucumr.pocoo.org/2014/11/6/error-handling-in-rust/ I don't know why so often, the immediate reaction to legitimate criticism of this wart in Go is to argue against exceptions, even when nobody has even brought up exceptions as an alternative.

thirsteh 12y ago
In fact, Either/Maybe can function like safer versions of both paradigms: Functors allow you to build a program of many functions that will terminate with 'Nothing' or 'Either l' as long as any one of them experiences an error, without thinking about errors, and it still lets you explicitly handle any errors if you want to, this time on the sum type Maybe or Either, meaning that you usually handle both the error and non-error case, or receive a compiler warning. I agree that, probably universally, the people who fervently argue for either exceptions or explicit Go-style error handling don't know about Maybe/Either/Result. Then again, all this is pretty much impossible to replicate in Go.
vezzy-fnord 12y ago
Option types are nice. The fourth way (and I think the best) is supervision trees, though this is more applicable when you have multiple units of execution... which Go does, so not having something similar out of the box seems strange. That said, even something as simple as errors being literal values that you can pattern match on is surprisingly versatile. Exceptions don't necessarily have to be awful weights that spill down all over the call stack, either. They can be distilled to a more basic catch/throw mechanism for shuffling around error properties and states.
- threeseed 12y ago
  Personally I love option types but working on a large Scala project at the moment it sometimes results in non ideal behaviour from developers especially those coming from the Java world. What I've seen a lot of is swallowing of errors. For example readFromFile().orElse("") where there is no indication from an outsider that anything wrong happened. A cool feature would be logging any instance of when orElse was the result. Would be curious how these work in other languages.
  - Jweb_Guru 12y ago
    The trick is to make it very ergonomic to return the error. I thought Scala had do notation to make this the case. In Rust, the try! macro (which returns on error) is shorter than almost any other way to handle an error, so people usually use that.
Dewie2 12y ago
Thank you for mentioning this. It's frustrating that every time someone complains about Go's error-handling style, the first assumption is that the complainer then necessarily has to prefer exceptions. In truth, errors-as-values are very elegant in languages like Haskell IMO. And errors-as-values are not at all something that Go has managed to put back on the roadmap in a modern language against the grain of everyone else (the "exception people") as many seem to imply, including Rob Pike in his "errors as values" article.

threeseed 12y ago

I'm confused what makes exception handling so troublesome ? Personally I find them essential in particular for larger codebases. They allow for centralised, consistent error handling behaviour. For example paging application support teams only for certain types of errors. And you can always emulate explicit error recovery with exceptions. So what is so bad about having the flexibilty to accomodate different styles of error handling.

xienze 12y ago
Yeah, I don't understand the objection to exceptions either. I _think_ the reason is because people treat them much the same was as errors in C/Go/etc., i.e., "I have to catch them here and recover right away." If you're doing it that way, you're doing it wrong. Design the system such that exceptions can be rethrown (bubbled up) and defer the handling as long as possible.
mike_hearn 12y ago
Nothing. This is one of those "Go doesn't have it, so it must be bad" things. The way Go handles errors is a throwback to C and was abandoned by literally every single imperative language for good reasons.

4ydx 12y ago

Honestly I wish that golang forced you to acknowledge all return values from methods even if you simply ignore them ( _ = Method() ). When I read the docs for any method calls in golang I like being able to see that something returns an error just by looking at the function signature. Certainly I might not know how to handle all the error variations, but not having to decide if I need to wrap something in try/catch... I dunno it just resonates with me.