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

71–80 of 127 posts

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

#71

Post by pjmlp »

lanstin wrote: post #56
marcus_holmes wrote: post #26

Earlier quoted context omitted.

I've spent the last year working on a Go system, writing Go every day. After a couple of months, I just stopped seeing/worrying about "if err != nil {". It has become punctuation, the Go equivalent of semicolons; I don't even use snippets; I manually type that every time. Which is good, because it does make me think about whether this function call can error, and what I should do about it if it does. 90% of the time…

So much this: "it does make me think about whether this function call can error, and what I should do about it if it does." This thinking is why C programs are the most reliable computing substrate - because errors can happen and there is no substitute for the programming taking a moment to think the possibilities of error. Build that thinking into the dev process, and you have a hope of reliability within the proces…

Yeah, they are so reliable. A living proof of good quality.

https://www.cvedetails.com/vulnerability-list/opmemc-1/memor...

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

#72

Post by kstenerud »

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, taking advantage of the return types of the function to automatically fill in named return values:

    func MyFunc(param int) (result int, err error) {
        result = 0
        if param > 0 {
            result = param + 10
        } else {
            try p1, p2 := GetInternalValues(param)
            result = p1 * p2
        }
        return result, err
    }
where "try p1, p2 := GetInternalValues(param)" is syntactic sugar for (in this case):

    var p1, p2 int
    p1, p2, err = GetInternalValues(param)
    if err != nil {
        return result, err
    }

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

#73

Post by [deleted] »

marcrosoft wrote: post #9

Please for the love of god no. Go is awesome for its simplicity. Errors should not be abstracted out of handling convenience. Errors are just values either eliminate the need for the error or handle it like you would any other value. Stop trying to make go work like every other language.

[deleted]

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

#74

Post by ngrilly »

jy3 wrote: post #55

Looks a lot like the already proposed check/handle keywords that was met with a lot of push back from the Go community: https://go.googlesource.com/proposal/+/master/design/go2draf... Doesn't look like the proposal adds anything new.

This new proposal is explicitly a simplification of the previous check/handle proposal. And for the record, there was a lot push back, but also a lot of support for the check/handle proposal. Language design is an iterative process.

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

#75

Post by kjeetgill »

captncraig wrote: post #24
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…

Every time I switch back to exception languages, I get this tendency to "assume everything succeeds all the time, and handle it at the very top level in case any part of it fails". I do not think about what can go wrong at each level nearly as much as I do when I am required to use `if err != nil` soup.

Coming from Java I agree: that's what tends to happen, but I miss it when I don't have it.

It's helpful habit for services especially because most of what you're doing is local to a request anyway and you want to "undo" or "drop" things. Exceptions in services are great because they actually preserve situational information pretty well and a catch+rethrow is pretty good for annotations at different levels. Err/panic are so poor at capturing anything of value by default. They require a ton of diligence to be useful.

The nice thing about being able to catch exceptions is that I can kinda define what operations are "atomic" on my terms.

Presumptuous example disclaimer.

For instance, if I'm processing a set of files with records, I'll probably have a substantial error domain around the processing of a record, of a whole file, and my whole program. I don't want to babysit each byte read.

Now, I admit, this does require you to write code that didn't pollute your state with partial work. Unwinding from a frame/function should leave everything in a known place.

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

#76

Post by marcus_holmes »

pjmlp wrote: post #65
jchw wrote: post #41

Earlier quoted context omitted.

I don’t like exceptions at all. They do not make it obvious what is going on, I never am completely sure if I’m handling them right. When I want to throw an exception I’m often unsure which would be right, and sometimes your API can have multiple reasons to throw the same exception. Go error handling is not like that. But I can sure as hell say fairly that Go error handling is likely also not similar to what you did…

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?

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

#77

Post by zimpenfish »

pjmlp wrote: post #65
jchw wrote: post #41

Earlier quoted context omitted.

I don’t like exceptions at all. They do not make it obvious what is going on, I never am completely sure if I’m handling them right. When I want to throw an exception I’m often unsure which would be right, and sometimes your API can have multiple reasons to throw the same exception. Go error handling is not like that. But I can sure as hell say fairly that Go error handling is likely also not similar to what you did…

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…

> but they are also very opinionated on what they impose on others.

I'd think anyone who creates a language is bound to be opinionated about what should be in a language, no?

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

#78

Post by grey-area »

politician wrote: post #66
grey-area wrote: post #57

Earlier quoted context omitted.

Don't do that then. This is just another tool in the toolbox, you don't have to use it at all. I think I'd use it in about half the cases where I return an error, in cases where I simply want to handle it one level up without further annotation.

Go is a managed language, and that management extends to how you are allowed to write the code. There aren't simply tools in the toolbox, fmt and lint enforce programming styles. In this community, it's accepted that if you didn't run `go fmt` on your code before committing that someone else will do it for you. If you don't fix all of the linter errors, you can expect contributions to be rejected. If try is adopted,…

I see no reason for the linter to recommend it unless you are using if err != nil {return err} - if you are, it is functionally the same, therefore no change and it would be recommended, which is fine IMO.

I don't really see the danger here - if you want to annotate errors properly, do so, if you want to respond in place (with a retry for example), do so, if you don't do either and just return the error (which is sometimes fine) yes the linter would recommend the shorter version.

Where's the problem?

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

#79

Post by coldtea »

codr7 wrote: post #10

I get that the error is still propagated "manually" behind the scene; but how is this different from exceptions in practice once you use try everywhere (except where you forgot and the error is dropped silently)? Here is my proposal: add restarts [0] as a complement to manual propagation. [0] https://github.com/codr7/g-fu/blob/master/v1/doc/typical_res...

>I get that the error is still propagated "manually" behind the scene; but how is this different from exceptions in practice once you use try everywhere

For one, the Go team hasn't invented exceptions, so they don't fit the NIH goals.

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

#80

Post by coldtea »

grey-area wrote: post #42
codr7 wrote: post #10

I get that the error is still propagated "manually" behind the scene; but how is this different from exceptions in practice once you use try everywhere (except where you forgot and the error is dropped silently)? Here is my proposal: add restarts [0] as a complement to manual propagation. [0] https://github.com/codr7/g-fu/blob/master/v1/doc/typical_res...

Because it doesn’t skip the call chain - each function must explicitly handle the error or pass it on. In practice usually errors are handled one or two levels up, not with some global error handler as people do with exceptions. Also the error is in the function signature, unlike exceptions. Also, you don’t use try everywhere, that’s the point. They could do with some better examples.

>Because it doesn’t skip the call chain - each function must explicitly handle the error or pass it on

So like, checked exceptions?

>Also the error is in the function signature, unlike exceptions.

So like, checked exceptions?

Post reply on HN