Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

111–120 of 127 posts

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

#111

Post by flavio81 »

marcus_holmes wrote: post #76
pjmlp wrote: post #65

Earlier quoted context omitted.

Yeah, until one realizes that most Go error handling is a mix of - Parsing error results inside strings - if .... else boilerplate - Underscore everywhere to silence them - Abuse from panic, aka exceptions in disguise If you want error handling without exception's guesswork, there are checked exceptions (used for the first time in CLU 1975), and result types (used for the first in ML in 1973) Both without the ceremon…

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?

>I sense some frustration about the language... what happened to make you so anti-Go?

Why makes you think everybody should be uppity and approving about Golang? Some of us feel is a step in the wrong direction.

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

#112

Post by pcwalton »

amluto wrote: post #68
pcwalton wrote: post #3

It's the try! macro from Rust! Obviously I'm a big fan of this style of error handling, and I'm happy to see it proposed for Go.

Except it’s missing the part where sum types are used, resulting in oddities about the non-error part of the return value when the error part is set.

I mean, sure, but it's the best they can do while remaining compatible with all the Go code out there.

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

#113

Post by blacksmythe »

dickeytk wrote: post #35
jerf wrote: post #6

Earlier quoted context omitted.

After chewing on this for a while, I've come to the conclusion that the thing exceptions does wrong (or if that is too controversial, substitute "most dangerously") is that it disconnects handling the error from the scope that generated it. It's the way exceptions so easily fly up the stack into code that can't understand them because it is too distant in context that is the problem. Neither this proposal, nor any ot…

on a side note, if I could just write `if err != nil return err` on a single line (without `go fmt` "fixing" it) that might be enough for me not to need `try`.

  >> without `go fmt` "fixing" it
Great point.

And this line should be indented relative to the 'happy path' lines!

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

#114

Post by codr7 »

jacques_chester wrote: post #88
arcticbull wrote: post #17

Earlier quoted context omitted.

Exceptions are the opposite of a goto statement, basically a 'comes-from' statement. They violate the principal of least surprise in every way possible -- you may have no idea what type is being sent your way, where from or what to meaningfully do about it as a result. They often result in memory leaks in languages like C++ due to lack of destructor invocation. try() errors can only propagate to the caller. As such,…

> 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...

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

#115

Post by est31 »

microtonal wrote: post #99
est31 wrote: post #8

Earlier quoted context omitted.

try! is dead, long live try.

Well, try! is dead quite literally. Rust still has the macro, but it is superseded by the ? operator.

That's the pun :). "The king is dead long live the king" originally comes from the French court and actually was used to refer to the old king dying and the heir to become the new king. https://en.wikipedia.org/wiki/The_king_is_dead,_long_live_th...!

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

#116

Post by grey-area »

ajcodez wrote: post #98
grey-area wrote: post #44

Earlier quoted context omitted.

This isn’t a replacement for go error handling, it’s a complement. Sometimes you don’t need to do anything other than pass an error up the chain.

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.

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

#117

Post by 013a »

kstenerud wrote: post #72

If it were a keyword rather than a pseudo-function, I would support its addition. Psuedo-functions should not be allowed into the language, as they tend to have side effects that you wouldn't expect from a function call (such as returning from caller to grandparent). Some keyword that implies "return if error" so that you could then do: try v1, v2, v3 := someFunction() You could even make it a little bit smart, takin…

Given that putting 'try' before the variable definitions would probably interfere with the 'var' keyword, it makes a bit more sense to me that it should be put after the assignment operator (something like var try v1 = Thing() is probably lexable consistently, but it would be confusing to remember if it goes var try v1 or try var v1, unless it supported both which seems ish)

    v1 := try someFunction()
I like that, primarily because it has echos of how the go keyword already operates. But the important thing is that it should be disallowed anywhere that isn't directly next to an assignment, which might be difficult. Like

    // compiler error
    fmt.Printf(try someFunction())
Not sure how easily that can be enforced without affecting the lexability of the grammar or compilation speed, but in a way, it should be thought of as a tokenized part of the assignment, not the RH-expression, such that the assignment tokens become

    =
    :=
    = try
    := try

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

#118

Post by uryga »

ngrilly wrote: post #108
uryga wrote: post #107

Earlier quoted context omitted.

it uses the same syntax as functions, but it doesn't behave like a function – functions generally can't manipulate control flow like that. so calling it a function is weird because it's closer to a language construct like `await`

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 language

(i'm a Haskell enthusiast, so please excuse the nitpicking :)

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

#119

Post by marcus_holmes »

boomlinde wrote: post #103
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?

> I sense some frustration about the language... what happened to make you so anti-Go? That's an utterly pointless derailment.

true, but I was curious

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

#120

Post by marcus_holmes »

grey-area wrote: post #101
pjmlp wrote: post #65

Earlier quoted context omitted.

Yeah, until one realizes that most Go error handling is a mix of - Parsing error results inside strings - if .... else boilerplate - Underscore everywhere to silence them - Abuse from panic, aka exceptions in disguise If you want error handling without exception's guesswork, there are checked exceptions (used for the first time in CLU 1975), and result types (used for the first in ML in 1973) Both without the ceremon…

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.

Post reply on HN