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

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

github.com

Post reply on HN
Print view View original

81–90 of 425 posts

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

#81

Post by nkozyra »

baby wrote: post #66
sagichmal wrote: post #52

Earlier quoted context omitted.

That feels about right, but missing the most important measure, IMO, which is it takes 10-100x less time to read and understand a new codebase.

I spent years as a consultant reading codebases in different languages. I can tell you that Golang win hands down for clarity of code and structure of projects (and perhaps second after Rust in terms of security. If only it had options ...) So yeah, it's actually quite fast to dig in a Golang codebase. You notice that as a normal user when you find it faster to read the standard library vs reading the doc, or when yo…

> My guess is that gofmt is a huge factor in this

It really is. My code looks like your code and the next person's code. Go is opinionated and strict and that makes reading other people's code so much easier

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

#82

Post by pcwalton »

unixsheikh wrote: post #63

This is great news. I really like how errors are handled in Go and I hated this proposal. The current implementation forces you to constantly think about errors at each single point and it is extremely good at standing out. This is something very valuable, not something that requires or needs to be hidden behind syntactic sugar. It improves the readability of the code and the quality of the software. If it ain't brok…

Go does not force you to think about errors at every single point. If a function returns only an error (such as, for example, os.Mkdir), the language will happily let you drop the error on the floor.

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

#83

Post by baby »

inimino wrote: post #48
quotemstr wrote: post #31

Earlier quoted context omitted.

I agree. Go does remind me a lot of early Java. And for some domains, you do want generic easy-to-produce uncreative code of the sort Go encourages. It's just that I personally do not want to work on a project for which the technical need to repeated uncreative execution. I want to explore new ways of solving problems, and Go is not the language for that. That's why use of Go is a reliable signal.

There's plenty of scope for creativity at higher levels of abstraction than the translation of algorithms into programs. Not being creative about error handling (for example) frees some of the creativity budget for things that I personally find much more interesting.

This. I have no idea what GP is referring to. I've seen some really beautiful code written in Golang. Check Let'sEncrypt.

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

#84

Post by mevile »

patientplatypus wrote: post #54

I mean... If you don't like writing `if err!=nil {...}` throughout your code base surely you can just create some middleware function in its own package that has switch statements based on error cases. Checking for errors frequently in the running of the code is more or less a Good Thing.

I don't see how a switch statement helps you avoid checking for errors when methods you use return errors, and a lot of methods return errors.

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

#86

Post by crimsonalucard »

guessmyname wrote: post #36
curtis wrote: post #11

A lot of Go programmers didn't like this proposal at all. I'd like to think this is just because they didn't think it was good enough. However, it seems that many, many Go programmers didn't like it because they think Go error handling is just fine the way it is.

I am one of the Go programmers who didn’t like this proposal. I also spent a significant amount of time discussing with many people, including the Go team, and I am glad the proposal was declined, not because I like “if err != nil {…}” but because the proposal to add “try()” was not solving a good problem. Many, and I would say, every Go programmer wants better error handling, but “try()” was not it. I hope the Go te…

The maybe monad is the best solution for this.

Usually to support this the language needs Enum support and a proper type system neither of which golang has. So I'm ok with the developers just baking in syntax for an error monad with specific sugar for extracting the value or handling an error.

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

#88

Post by nkozyra »

patientplatypus wrote: post #54

I mean... If you don't like writing `if err!=nil {...}` throughout your code base surely you can just create some middleware function in its own package that has switch statements based on error cases. Checking for errors frequently in the running of the code is more or less a Good Thing.

I see this a lot in example code and I hate it. Don't hand off error handling to some other function, return then and there, bubbling up whatever went wrong.

Most of the time the receiver is swallowing the error or spitting it to stdout, so why bother

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

#89

Post by nine_k »

0815test wrote: post #10
jph wrote: post #4

Kudos to the Go team for their process on this. IMHO it's worth reading Russ Cox's explanation of the problem area, including examples, and comparisons to other languages e.g. Rust and Swift. https://go.googlesource.com/proposal/+/master/design/go2draf...

"But Rust has no equivalent of handle: the convenience of the ? operator comes with the likely omission of proper handling." what's that supposed to mean? The ? operator just bails out if an Error result is returned from the called function, and forwards that Error to the caller. Cleanup is performed implicitly by drop implementations (destructors) using the RAII pattern ala C++.

Indeed, Go has no RAII.
Post reply on HN