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

131–140 of 425 posts

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

#131

Post by MaulingMonkey »

Arnavion wrote: post #111
MaulingMonkey wrote: post #80

Earlier quoted context omitted.

As Arnavion points out, handle handles multiple error cases. That said, I'm not convinced it's better in practice . For some comparison points - here's how I'd write the Go CopyFile in Rust: https://play.rust-lang.org/?version=stable&mode=debug&editio... Or, if we want to keep a more 1:1 direct mapping to the Go code: https://play.rust-lang.org/?version=stable&mode=debug&editio... Caveats with the "1:1" mapping: 1) I…

>1) In a real rust codebase you'd probably simply forward std::io::Error instead of converting it into a string like I have here, or give it a better error struct/enum type. In all the real code bases I've worked on, there are multiple disparate types of errors that nevertheless have the same context. Example: A function that takes in a path and parses a config file at that path fails if it can't open the file or if…

`?` uses the `From` trait which means you often don't need `.map_err`. Ignoring crates like error_chain, even the stdlib comes with a From implementation for `Box` - as long as your error types implement std::error::Error, you shouldn't need an explicit .map_err to box them:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

EDIT: That said, adding extra context will often require map_err or similar. But merely type erasing / combining error sources shouldn't need it, unless I'm missing something. (Most of my Rust use so far has been on toy codebases...)

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

#132

Post by schrodinger »

KirinDave wrote: post #112
stcredzero wrote: post #92

Earlier quoted context omitted.

So long as we can all agree that it feels super bad, I guess this is fine Exceptions feel super good, even as you're taking too many shortcuts and glossing over things. Proper handling of the unhappy paths is often going to feel like a slog, because it often is complicated, and it's often a slog. Glossing over error handling in golang can feel bad exactly when it should.

> Exceptions feel super good, even as you're taking too many shortcuts and glossing over things. I'm not sure I follow this talk about "short cuts.". Exceptions provide stronger guarantees by default than multiple-value-bind and manual if statements. Your code fails closed as opposed to open. > Proper handling of the unhappy paths is often going to feel like a slog, because it often is complicated, and it's often a s…

go vet catches that scenario and won’t pass CI. You have to explicitly decide to ignore it by using an underscore for the err value and then you get just what you asked for.

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

#133

Post by stockkid »

013a wrote: post #68
AnimalMuppet wrote: post #17

Earlier quoted context omitted.

I don't understand why anyone would be (strongly) against this proposal. If I understand it correctly, it's just a shortcut. That is, the old (existing) way would still work. If anyone didn't like "try", well, don't write your code that way. It would also appear to be amenable to an automated tool that would convert to or from try-style. Given that, why would people have strong feelings against? Because they think go…

This is the prime example of what makes Go different than most other languages. They don't put things in attached with the argument "if you don't like it, you don't have to use it." Go is a language designed to be written and read by teams. You don't like try. Bob does. Bob writes code that uses it. You still have to read it.

> They don't put things in attached with the argument "if you don't like it, you don't have to use it."

I agree with this. I think many Go users like Go because of its simplicity that prevents unnecessary bikeshedding so prevalent in other languages.

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

#135

Post by abtinf »

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…

Go is the only language where I look at the standard library source instead of google whenever I run into an ambiguity in the docs. I think there are three reasons for this.

First, the docs link to the actual line in source, so it’s just a click away and available in the exact context I need it.

Second, I know I’ll be able to understand it: there are usually very few dependencies, so I can usually get all the context I need from a single file; the source formatting is familiar; code style, like variable names, are familiar because of the cultural influence of the Tour of Go; and there is usually no magic anywhere—I know that things are exactly what they appear to be, like when I see a variable declaration, it is not secretly calling a complex function (this is vital to human knowledge and is aligned with Objectivist epistemology’s “law if identity”).

Third, every time I look at the standard library source, I become a better programmer. I’ve lost track of the number of times I’ve thought to myself “oh, that’s a clean way to organize this kind of code!” I often end up immediately using what I learn from the stand library source.

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

#136

Post by UK-AL »

bmurphy1976 wrote: post #116
inlined wrote: post #41

Earlier quoted context omitted.

> errors being values Though with generics we could have the error values be less invasive. Learning the Scala mindset was eye opening. For e.g. the design patterns of an Optional[T]’s primary code flow are the same as a Try[T,E]. With common transformation idioms, you learn to recognize code patterns the same way one might recognize data structures. It’s no less magical and it simplifies greatly.

But it doesn't simplify, it just moves the complexity around. That's not necessarily bad, you get better safety guarantees as a result but you also spend more time fighting the compiler and locked in design space trying to get a model that works (and even MORE time is spent if you want it to be readable and something that other people can grok quickly). I don't see this as an either/or situation. There's a continuum…

Honestly I think moving to towards Idris/coq level type systems saves more time in the long run.

Being close c means you discover errors at run time, then you have to come back to cover them.

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

#137

Post by EdwardDiego »

tempsolution wrote: post #55
KirinDave wrote: post #45

Earlier quoted context omitted.

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…

You can't compare it to Java checked exceptions. Java checked exceptions are one of those billion dollar "mistakes". It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code. For that comparison to work, java would have needed to only have checked exceptions, with some added language features to deal with them cleanly, and then it might actuall…

My most hated checked exception is the IOException Jackson throws when parsing JSON I can guarantee to be valid JSON.

I could live with a runtime exception, or perhaps an API that differentiates parsing "potentially not-parseable JSON" and "JSON I can vouch for".

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

#138

Post by bmurphy1976 »

AnimalMuppet wrote: post #17
rbtprograms wrote: post #6

Good on the Go Team listening to the community, I definitely saw more people against this feature than for it. I hope they take another stab at improving error handling. I like Go a lot and do think error handling is one place it could use improvements.

I don't understand why anyone would be (strongly) against this proposal. If I understand it correctly, it's just a shortcut. That is, the old (existing) way would still work. If anyone didn't like "try", well, don't write your code that way. It would also appear to be amenable to an automated tool that would convert to or from try-style. Given that, why would people have strong feelings against? Because they think go…

It's just a shortcut... in a language that has very few shortcuts, very few abstractions whatsoever, and certainly none that look or behave like try would.

It complicates the language for little gain. It's good that they punted on this for now.

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

#139

Post by nemothekid »

Arnavion wrote: post #111
MaulingMonkey wrote: post #80

Earlier quoted context omitted.

As Arnavion points out, handle handles multiple error cases. That said, I'm not convinced it's better in practice . For some comparison points - here's how I'd write the Go CopyFile in Rust: https://play.rust-lang.org/?version=stable&mode=debug&editio... Or, if we want to keep a more 1:1 direct mapping to the Go code: https://play.rust-lang.org/?version=stable&mode=debug&editio... Caveats with the "1:1" mapping: 1) I…

>1) In a real rust codebase you'd probably simply forward std::io::Error instead of converting it into a string like I have here, or give it a better error struct/enum type. In all the real code bases I've worked on, there are multiple disparate types of errors that nevertheless have the same context. Example: A function that takes in a path and parses a config file at that path fails if it can't open the file or if…

You don’t need the `map_err` if you are using `?`

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

#140

Post by chc »

natefinch wrote: post #98
KirinDave wrote: post #45

Earlier quoted context omitted.

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…

Literally the first non-trivial code I wrote in go (running a bunch of goroutines to download a ton of files from a website in parallel)... I knew exactly where and how things could fail and where things were failing just by looking at the code. Coming from C++ and C# and Python, there was no comparison. I had never been so confident in the code I'd written, even though I was a newbie at Go and a veteran of the other…

I don't see how allowing ergonomic features like try into the language would hamper this. For example, Rust also represents errors as return values — you know exactly where and how things could fail just by looking at the code for a function — but it still has the equivalent of Go's proposed try.
Post reply on HN