4 ms·

This thread is rife with "Go should have Try because I want Try" that also seem to be made by developers that do not write Go. It seems confusing to me that voi

This thread is rife with "Go should have Try because I want Try" that also seem to be made by developers that do not write Go. It seems confusing to me that voices generally involved from Go are so demanding of its maintainers. Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try?

qtplatypus 7y ago
I am a full time developer in go. I feel the lack of good error handling every time I write a function call and then have to use the same if statement to check its result.
- ngrilly 7y ago
  Have you contributed to the discussion about `try` in the GitHub issue tracker?
apta 7y ago
> Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try? I use golang at an employer. error handling in golang is verbose, error prone, distracting, and difficult to make sense of when there is actually an error (composing). I've seen on several occasions now errors being mishandled (either dropped by accident, or by overwriting already existing error variables in the same scope). These issues don't happen with exceptions.
- abhink 7y ago
  It's interesting that as a full time Go developer myself, my experience has been very different about the points you have mentioned. I personally think verbosity is good. For one, lack of verbosity catches my attention. If I am reviewing code that looks like some part of it is ignoring the error, I would try to find a reason about that error check exclusion. This also prevents errors being dropped by accident. About overwriting, again this has never been a problem for me (as far as I can recall). Error values are very much localised in almost all Go code I have seen and written. If a function returns an error it is either immediately acted upon or returned by the caller. As such, any overwriting done at a later stage is more or less for convenience sake.
  - fredmorcos 7y ago
    > This also prevents errors being dropped by accident. Instead of designing a language that prevents errors from being dropped by accident, hire a bunch of literal gophers to search your codebase for inverbosity. Good plan will work 10/10 times.
- sethammons 7y ago
  And this is what you could use to write up an experience report concrete, as in real, actual happened events. Here is what we have faced in production type thing. The maintainers want that. They don't want hypotheticals no matter how logical or obvious they might be. These feed improvements. I'd encourage you to write that up.
- ngrilly 7y ago
  Have you contributed to the discussion about `try` in the GitHub issue tracker?
dalyons 7y ago
I write a lot of go in the context of web(micro)services. In stateless services it’s almost always better to bubble up the error and let the caller retry. So I hate the current error handling in this context, it’s a verbosity tax with no value add. Am ambliviant about try though
- ngrilly 7y ago
  Have you contributed to the discussion about `try` in the GitHub issue tracker?
break_r 7y ago
> Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try? I am a full-time Go developer. Error handling in Go is miserable. `try` would have made it slightly less miserable.
- ngrilly 7y ago
  Have you contributed to the discussion about `try` in the GitHub issue tracker?

qtplatypus 7y ago

I am a full time developer in go. I feel the lack of good error handling every time I write a function call and then have to use the same if statement to check its result.

ngrilly 7y ago
Have you contributed to the discussion about `try` in the GitHub issue tracker?

apta 7y ago

> Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try? I use golang at an employer. error handling in golang is verbose, error prone, distracting, and difficult to make sense of when there is actually an error (composing). I've seen on several occasions now errors being mishandled (either dropped by accident, or by overwriting already existing error variables in the same scope). These issues don't happen with exceptions.

abhink 7y ago
It's interesting that as a full time Go developer myself, my experience has been very different about the points you have mentioned. I personally think verbosity is good. For one, lack of verbosity catches my attention. If I am reviewing code that looks like some part of it is ignoring the error, I would try to find a reason about that error check exclusion. This also prevents errors being dropped by accident. About overwriting, again this has never been a problem for me (as far as I can recall). Error values are very much localised in almost all Go code I have seen and written. If a function returns an error it is either immediately acted upon or returned by the caller. As such, any overwriting done at a later stage is more or less for convenience sake.
- fredmorcos 7y ago
  > This also prevents errors being dropped by accident. Instead of designing a language that prevents errors from being dropped by accident, hire a bunch of literal gophers to search your codebase for inverbosity. Good plan will work 10/10 times.
sethammons 7y ago
And this is what you could use to write up an experience report concrete, as in real, actual happened events. Here is what we have faced in production type thing. The maintainers want that. They don't want hypotheticals no matter how logical or obvious they might be. These feed improvements. I'd encourage you to write that up.
ngrilly 7y ago
Have you contributed to the discussion about `try` in the GitHub issue tracker?

dalyons 7y ago

I write a lot of go in the context of web(micro)services. In stateless services it’s almost always better to bubble up the error and let the caller retry. So I hate the current error handling in this context, it’s a verbosity tax with no value add. Am ambliviant about try though

ngrilly 7y ago
Have you contributed to the discussion about `try` in the GitHub issue tracker?

break_r 7y ago

> Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try? I am a full-time Go developer. Error handling in Go is miserable. `try` would have made it slightly less miserable.

ngrilly 7y ago
Have you contributed to the discussion about `try` in the GitHub issue tracker?