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

61–70 of 127 posts

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

#61

Post by frou_dh »

dickeytk wrote: post #7

is it just me or does the word "try" seem to imply the opposite here? To me saying "try" is like saying "attempt to run this" like we have in a try/catch block. I feel like something like "expect" would more directly explain what this does. Great functionality though. I'd be very happy to see this included no matter what it's named. EDIT: This is answered in the FAQ section after I read further. Apparently it's becau…

See also the "continue" statement in C/Go/etc for something that does the opposite of what the word suggests.

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

#62

Post by grey-area »

stepforward wrote: post #5

If there are multiples `try` inside a single function, and we are debugging and want to know which call raises error, how can we do that? Should `try` wraps the error and adds something more useful for debugging purpose? (the line number probably?)

Maybe don't use this try if you want more detailed info on specific errors? It's for using where you would use if != nil return err not in every instance. If you try to use it everywhere it won't work well.

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

#63

Post by politician »

hliyan wrote: post #4

So basically they're proposing: f, err := os.Open(filename) if err != nil { return …, err // zero values for other results, if any } can be simplified to f := try(os.Open(filename)) This makes a lot of sense, but I'm of two minds. On one hand, it makes things much cleaner. On the other hand, it might be a first step onto a slippery slope that ends with exceptions. A lot of others chiming in with different ideas on th…

This is certainly following the path of JavaScript Promises which do, as you say, end in exceptions.

It would be nice to skip directly to `try func() error{}()` and avoid that specific pain.

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

#64

Post by [deleted] »

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

[deleted]

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

#65

Post by pjmlp »

jchw wrote: post #41
pjmlp wrote: post #28

Earlier quoted context omitted.

I used to write code like that during the 80 and 90's, until settling down in languages with first class support for exceptions. So yeah, I did it for around 20 years, and don't miss it.

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 ceremony that Go shares with Algol derived languages before exceptions were a thing.

Rob Pike and friends surely do know a lot about what programming was like at that time, but they are also very opinionated on what they impose on others.

Just because they have a very good career, it doesn't make them always right.

I tend to think for myself and not from opinions of others.

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

#66

Post by politician »

grey-area wrote: post #57
cientifico wrote: post #51

The interesting part for me about the current form is that it makes me think what should be the state on the rest of the ecosystem in case an error happens. That extra lines, as for experience, pays off quite fast. This form puts to the background that though, and I fear I feel tempted to put try everywhere.

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, we can expect to see the linter pushing its usage aggressively. The OP will be pressured to use it, and ultimately has no say in whether they use it less than the linter demands and social expectations for idiomatic usage compels.

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

#67

Post by pjmlp »

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.

It is from a core team member, usually those proposals tend to win in the end, as already occurred a couple of times.

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

#68

Post by amluto »

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.

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

#69

Post by bsaul »

I used to be a bit skeptical on the slow pace at which go decided to add new feature, and the insane care they took to have orthogonal features, but after seing the recent swift language evolution ( with google team pulling it toward dynamic features, and now apple adding weird and clumsy DSL support) i must say i’m now completely supporting their choice. taking a year before settling on a less ambitious but more orthogonal and minimalist feature is a sign of wisdom.

it is amazing the speed at which a language can go from something elegant to a mess.

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

#70

Post by akavel »

ithkuil wrote: post #37
stepforward wrote: post #5

If there are multiples `try` inside a single function, and we are debugging and want to know which call raises error, how can we do that? Should `try` wraps the error and adds something more useful for debugging purpose? (the line number probably?)

Yeah, that was my first thought as well. I'm using the juju/errors library "return errors.Trace(err)", which annotates the error with the line number of the return. That wouldn't work in a deferred function. Perhaps the compiler could make that possible somehow although I suspect that might conflict with the stated goal of improving the efficiency of defer due to "try" encouraging more people to use it.

A deferred function is called at the line where return would happen, so you can still access stack trace information required for errors.Trace(err) from inside a deferred function. You just need to go "one frame higher". (See the stack trace printed in: https://play.golang.org/p/Bpqdm8oWBF3).

As a result, I believe juju/errors could then be extended with a new function, to be used like this:

    func foobar(...) (..., err error) {
        defer errors.Tracify(&err)
        ...
    }
where:

    package juju/errors

    func Tracify(err *error) {
        if *err != nil {
            *err = TraceFromDefer(*err)
        }
    }
Post reply on HN