Hacker News Reader

Comment by throw_m239339 | Hacker News Reader

Go error handling is barely better than C error codes.

   int foo(int * return_value){ …; return 0 }

That's what Go does. There is no "error handling" baked into the language, aside from panics, it's a convention. It's not "awesome", it's primitive. You can do that in any language, and you don't when you have access to more evolved constructs.

View on HN

That's not exactly what Go does, as you can return much more information and it's almost always clear what's an error and what isn't (there are a few exceptions, such as strings.Index() returning -1).

strings.Index() => -1 is not an error, but a result, ie. empty result is not an error. A more sophisticated type system would provide more differentiation, but that also have costs.

Golang's errorhandling, I wouldn't say it's great, but it let's you be explicit about the errorhandling itself, which may lead to performant quality code. I believe it follows C errorhandling by design, but answers the age old "wish I could return an error in addition to return value here". Golang grants that wish, and even provides some compile errors if error value is not assigned to. Handling the error is left as an exercise though, so code shouldn't be too complex.

Index() returning -1 is natural for typical usage, when following conventions such as used in C-type languages. It seems to be a feature, appreciated by many, though with costs and benefits attached.

> That's not exactly what Go does, as you can return much more information and it's almost always clear what's an error and what isn't (there are a few exceptions, such as strings.Index() returning -1).

Yes it is exactly what Go does. Look, I'm "returning" an "out" parameter from my C function here. I can also return an "out" error in form of a "struct * error_return" if I wanted to, with a char * member or whatever.

This is not error handling baked in C either, just like Go. There is nothing "awesome" with doing that. I could do that in any language and nobody would call that "awesome".

Go errors are a specific type and that type is extensible. You can attach additional data to an error, and in recent versions of go you can wrap errors in other errors. You can do instance checking against an errors.New error, or do a type check against the kind of error you get back. This ultimately gives you significantly greater control and functionality over error codes.

Go errors are a convention. Nothing forces you to use error interface to do anything nor handle anything either.

See my comment here:

https://news.ycombinator.com/item?id=23759196

> You can attach additional data to an error, and in recent versions of go you can wrap errors in other errors.

Yes, with a function added to the std lib after people used a 3rd party lib for years to do the same thing. Nothing to do with a change of language structure or features.

You could do much of that with C structs as well.

Reply on news.ycombinator.com