51–60 of 127 posts
This form puts to the background that though, and I fear I feel tempted to put try everywhere.
This is interesting, but I think it doesn't necessarily fit the language well. 1. Go has very few keywords relative to other newish languages like Swift and Kotlin. Introducing a new one should only be done if the benefits are undeniable. 2. It causes an early return without any use of the "return" keyword, which feels pretty weird. 3. It's a bit weird that err will be magically defined in a defer function if the sur…
2. Returning if there is an error is the whole point of this proposal.
3. I don't understand your point. Could you provide an example?
4. try is explicit. There is no implicit behavior or stack unwinding.
We're returning pointers almost everywhere along with an error, even simple methods that could do fine without. But the n you feel obligated to check them instead of ignore them, just in case someone does change the implementation of the simple function.
I feel like in some of the projects I wrote for myself, I use a lot less error handling and then I don't mind the 'if err != nil' approach anymore.
I'm sure this `try` keyword will help deal with the pain from the codebase I'm working on, though it doesn't adress the root of our problem :(
To give an idea, in a function that does 5 other function calls, I need to check error returns 5 times. Every. Single. Line. That can't be the norm, right? :P
I love Go, but error handling can become cumbersome. Though, I also think a lot of that feeling is because at the codebase I'm working on we return too many errors in a strange way. We're returning pointers almost everywhere along with an error, even simple methods that could do fine without. But the n you feel obligated to check them instead of ignore them, just in case someone does change the implementation of the…
It's one of the pitfalls of using an opinionated language. I don't think introducing something like this will work because it is also a hack that will propagate other hacks in your code. Just return errors in a more standard way(or stop using Golang)
https://go.googlesource.com/proposal/+/master/design/go2draf...
Doesn't look like the proposal adds anything new.
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…
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.
Well, yet another magic function.
I suspect the downside is that it'll promote blind propagation of errors. In rust that's fine because the type system will document what error types can be returned. In golang, it important that every error type that can be returned is manually documented. Otherwise, it's better to just panic, since nobody can handle unknown errors anyways.. Or am I missing something?
Not really. You can just check if “err != nil” and switch control flow on this.
I think check/handle is much better than this.