Proposal: A built-in Go error check function, try • Hacker News Board

Re: Proposal: A built-in Go error check function, try

#121

Post by marcus_holmes » Thu, Jun 06, 2019, 7:42 AM UTC

pjmlp wrote: post #90

marcus_holmes wrote: post #76

Earlier quoted context omitted.

You've read a lot of very bad Go code then, that doesn't follow any of the established practices for it. Your list there is almost a primer of "what not to do in Go", and is certainly not representative of the Go code in e.g. the standard library. I sense some frustration about the language... what happened to make you so anti-Go?

You mean like this standard library code? https://go.googlesource.com/proposal/+/master/design/go2draf... > I sense some frustration about the language... what happened to make you so anti-Go? Go is C with GC and bounds checking, aka Limbo reborn with some Oberon-2 influence. Already much better for our IT safety than sticking with C, still I kind of expected Google capable of producing Swift, Rust or TypeScript leve…

that's not standard library code? that's a link to one of the few thousand proposals for changing Go error handling... I'm not sure what you're trying to say here...

I think keeping Go this simple was an extremely hard thing to do for the designers. I don't know what the intentions were for Swift or Rust, but the Go team were always pretty straightforward that what they wanted was a safer C to write servers in. I think we all agree that they achieved that.

Re: Proposal: A built-in Go error check function, try

#122

Post by ngrilly » Thu, Jun 06, 2019, 8:30 AM UTC

uryga wrote: post #118

ngrilly wrote: post #108

Earlier quoted context omitted.

We already have one built-in function that alters the control flow: panic. But I agree it's a bit weird.

tbh i don't know Go too well. as i understand it, `panic` can indeed hijack the control flow, i.e. stop it. but any function¹ can do that: just do `while 1 {}`! control flow won't return to the caller either way. so it's not that weird after all Ruby blocks can do non-local control flow, i.e. return from their surrounding function, but that's what makes them distinct from functions. --- ¹ in a turing-complete languag…

A panic can be recovered with recover(), and thus the program can continue. While a function that does an infinite loop will halt the program and nothing else.

Re: Proposal: A built-in Go error check function, try

#123

Post by grey-area » Thu, Jun 06, 2019, 8:43 AM UTC

marcus_holmes wrote: post #120

grey-area wrote: post #101

Earlier quoted context omitted.

Parsing error results inside strings Fair point - this is a nasty result of their simple interface, and I think a mistake given much of the std lib doesn't use concrete types behind the interface. fmt.Errorf leads directly to this. It's simple, but not very flexible and can lead to horrible habits like parsing strings. if .... else boilerplate It's more like if boilerplate. People don't tend to use else unless absolu…

> parsing error results inside strings I don't know why this is a thing. I create an explicit type for errors that I know I'm going to do something with, and do type assertions to check for them. I believe this was the intention behind the design in the first place.

Because many libraries (including stdlib) return basic errors which you can do nothing else with.

I think that's the main problem with this design - you're reliant on others to produce errors you can reliably check against, and every library could potentially have its own error types (similar to the problems with a proliferation of exception types in languages using exceptions). When using your own libraries it is not a huge problem - as you say you can start using a more complex type.

Not sure what the answer is, but the error interface which only allows returning a string is partly to blame IMO.

Re: Proposal: A built-in Go error check function, try

#124

Post by jacques_chester » Thu, Jun 06, 2019, 12:25 PM UTC

codr7 wrote: post #114

jacques_chester wrote: post #88

Earlier quoted context omitted.

> you may have no idea what type is being sent your way, where from or what to meaningfully do about it as a result. How is this different from (a) errors bubbling up with a pile of concatenated strings as the only type information or (b) errors not bubbling up because someone decided they would never make a mistake? The whole value of exceptions, to me, is consistency. The error is guaranteed to propagate in a consi…

There's no need to unwind the stack to get what you want. Restarts [0] evaluate the error handler in the throwing scope/environment and the only way out of there is invoking a predefined restart or aborting the program. [0] https://github.com/codr7/g-fu/blob/master/v1/doc/typical_res...

I'm aware of, but have never used, the CL conditions/restarts mechanism. It seems amazing but I wonder if it would manage to seem foreign to everyone in one of these discussions.

Re: Proposal: A built-in Go error check function, try

#125

Post by pjmlp » Thu, Jun 06, 2019, 2:23 PM UTC

marcus_holmes wrote: post #121

pjmlp wrote: post #90

Earlier quoted context omitted.

You mean like this standard library code? https://go.googlesource.com/proposal/+/master/design/go2draf... > I sense some frustration about the language... what happened to make you so anti-Go? Go is C with GC and bounds checking, aka Limbo reborn with some Oberon-2 influence. Already much better for our IT safety than sticking with C, still I kind of expected Google capable of producing Swift, Rust or TypeScript leve…

that's not standard library code? that's a link to one of the few thousand proposals for changing Go error handling... I'm not sure what you're trying to say here... I think keeping Go this simple was an extremely hard thing to do for the designers. I don't know what the intentions were for Swift or Rust, but the Go team were always pretty straightforward that what they wanted was a safer C to write servers in. I thi…

Apparently you didn't bother to read it.

Re: Proposal: A built-in Go error check function, try

#126

Post by ajcodez » Sat, Jun 08, 2019, 7:23 PM UTC

grey-area wrote: post #116

ajcodez wrote: post #98

Earlier quoted context omitted.

I would rather every developer takes a second while writing out “if err != nil” to decide how to add context or maybe return a new error with useful metadata.

It's not really about being lazy, sometimes there is nothing useful to add. I removed some error annotations the other day as they were just cluttering logs without adding usefully to an error for farther down the call stack. Sometimes you don't need to annotate/wrap.

Yeah that’s something you can decide too, while typing it out. It’s not about having extra context every time, it’s about deciding. Sometimes you want to ignore the error and take the zero value. Adding try to the language creates a new path of least resistance that decreases code quality.

Re: Proposal: A built-in Go error check function, try

#127

Post by grey-area » Mon, Jun 10, 2019, 6:57 PM UTC

ajcodez wrote: post #126

grey-area wrote: post #116

Earlier quoted context omitted.

It's not really about being lazy, sometimes there is nothing useful to add. I removed some error annotations the other day as they were just cluttering logs without adding usefully to an error for farther down the call stack. Sometimes you don't need to annotate/wrap.

Yeah that’s something you can decide too, while typing it out. It’s not about having extra context every time, it’s about deciding. Sometimes you want to ignore the error and take the zero value. Adding try to the language creates a new path of least resistance that decreases code quality.

You can't decide to avoid the boilerplate though at the moment, because there is no try. You can only type out the boilerplate, and read it, even if you don't really need it in that particular instance.

It would not reduce code quality if used in instances where it replaces return nil, err - which is what it is intended for. It's not intended to replace wrapped errors, or error handling, it's intended to replace 3 lines of boilerplate with one word - in the cases where you want to push the error one level up the call stack.

Having used go extensively for the last 5 years and built some large projects with it, I disagree this is not useful. I think it's a good proposal in the spirit of go and should be adopted.

I'd prefer this as a keyword myself, but of the 6 million instances of if err != nil on github, I think around half could be eliminated by this pattern, so I think it would be useful, if not overused.

https://github.com/search?l=Go&q=if+err+%21%3D+nil+%7B&type=...