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

21–30 of 127 posts

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

#21

Post by mwaitjmp »

axaxs wrote: post #14
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.

Agreed. This is the hill I'll die on. Boring error handling is what I specifically love about Go...

Out of interest, how about the proposed check and handle changes proprosed for v2?

Details here: https://dev.to/deanveloper/go-2-draft-error-handling-3loo

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

#22

Post by jchw »

cpuguy83 wrote: post #20

Error handling is, to me, the most important thing when writing any code. Promoting "if err != nil { return }" even more by giving it a keyword seems like a dangerous road to walk down. Are we proposing solutions to make developers not have to type "if err != nil" or are we looking at how we can help developers handle errors better and be more productive? I honestly don't have anything to offer as far as ideas for ch…

I think the way Go error handling works is fantastic, and one of the few problems it has is repetition. There’s C++ macros for various environments that let you do the assign-or-propagate-error stuff with a bit less repetition, but I dislike them because they feel opaque; people don’t often feel the potential consequences and just use it as a way to not think about error handling. With Go, the error handling behavior is so obvious and in your face that it’s painful. (This doesn’t stop bad error handling hygiene, but it has definitely helped me.)

Sadly, there’s no obvious dumb way to reduce that repetition. I would not mind a language mechanism similar to defer, like the handle/check proposal for example.

The most obvious issue I take with try is that it looks like a function call but is much more magical :( and also, I dislike named returns.

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

#23

Post by axaxs »

mwaitjmp wrote: post #21
axaxs wrote: post #14

Earlier quoted context omitted.

Agreed. This is the hill I'll die on. Boring error handling is what I specifically love about Go...

Out of interest, how about the proposed check and handle changes proprosed for v2? Details here: https://dev.to/deanveloper/go-2-draft-error-handling-3loo

Still not a fan. These seem like schemes for people who are annoyed by errors, and just throw them over the wall... similar to say putting an entire python block in a try/except.

With any sufficiently large application you start to realize how awful that is, especially when something fails and the only log is 'EOF'.

I've learned to treat errors as first class citizens, because they are. I always add an annotation and stack entry via wrappers before returning them. Unless I'm missing something, that seems all but impossible with these schemes.

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

#24

Post by captncraig »

jerf wrote: post #6
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…

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.

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

#25

Post by nmadden »

tedunangst wrote: post #15
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...

The error can't go through a function that doesn't return an error, unlike exceptions. Also, you have to ask for this. Reversing the default is a big difference.

Unlike unchecked exceptions.

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

#26

Post by marcus_holmes »

jchw wrote: post #22
cpuguy83 wrote: post #20

Error handling is, to me, the most important thing when writing any code. Promoting "if err != nil { return }" even more by giving it a keyword seems like a dangerous road to walk down. Are we proposing solutions to make developers not have to type "if err != nil" or are we looking at how we can help developers handle errors better and be more productive? I honestly don't have anything to offer as far as ideas for ch…

I think the way Go error handling works is fantastic, and one of the few problems it has is repetition. There’s C++ macros for various environments that let you do the assign-or-propagate-error stuff with a bit less repetition, but I dislike them because they feel opaque; people don’t often feel the potential consequences and just use it as a way to not think about error handling. With Go, the error handling behavior…

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 it's ("just pass it up"), 5% of the time it's ("nothing, I don't actually care if this routine fails") but 5% of the time it's ("right, yes, this needs to be dealt with here").

When reading code, I just skip over it if it doesn't do anything interesting.

I understand that in English reading, we don't notice "they said"; our brains just skip over it, and you can use "said" to open every quote and it won't feel repetitive. That's how I've got with "if err != nil {"

so... I'm against this "try" stuff, because it feels like it's been proposed by people who haven't worked with the language too much. I'm not against making it more friendly for new people to learn, but this doesn't feel like that. This just feels like "ugh, really? I have to handle all the errors?!"...which is not a reason to change it.

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

#27

Post by pjmlp »

umurgdk wrote: post #18

I am strongly against this. `try` seems exactly like a function yet it is not acting like a function at all. People wouldn't expecting calling a function may return from the caller. And there is a reason why golang doesn't have macros. With macros all kind of craziness would be possible, and would really difficult to read different kind of projects' code.

Go kind of has macros, like everything else, Go's solution to first level features in other languages is called //go:generate.

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

#28

Post by pjmlp »

marcus_holmes wrote: post #26
jchw wrote: post #22

Earlier quoted context omitted.

I think the way Go error handling works is fantastic, and one of the few problems it has is repetition. There’s C++ macros for various environments that let you do the assign-or-propagate-error stuff with a bit less repetition, but I dislike them because they feel opaque; people don’t often feel the potential consequences and just use it as a way to not think about error handling. With Go, the error handling behavior…

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…

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.

Post reply on HN