5 ms·

> 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

by 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?

by apta 7y ago

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?