Declined Proposal: A built-in Go error check function, “try” • Hacker News Board

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

#141

Post by bmurphy1976 » Wed, Jul 17, 2019, 1:51 AM UTC

UK-AL wrote: post #136

bmurphy1976 wrote: post #116

Earlier quoted context omitted.

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.

For humongous projects or critically important ones I'd agree with you, but for smaller/mid sized projects I can't agree. I think it's total overkill in many instances.

Would be nice if there was a language that scaled from C to Idris gracefully, but C++ and Scala make me think that's a pipe dream.

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

#142

Post by shanemhansen » Wed, Jul 17, 2019, 1:55 AM UTC

wybiral wrote: post #33

This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Do I particularly like managing errors that way? No, but I do think that it improves the transparency and qual…

Do I like verbose errors? No. Do I like explicit errors? Yes. This is why generics and a Result type will be nice because we will be able to factor out that explicit error handling.

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

#143

Post by KirinDave » Wed, Jul 17, 2019, 1:55 AM UTC

schrodinger wrote: post #132

KirinDave wrote: post #112

Earlier quoted context omitted.

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

Sure, but it doesn't catch the case where you have multiple error variables in scope and you refer to the wrong one in one place but not the other or if you reuse an error.

I've seen that happen more than a few times. Some of it in new production code.

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

#144

Post by sagichmal » Wed, Jul 17, 2019, 1:56 AM UTC

pcwalton wrote: post #106

jchw wrote: post #94

Earlier quoted context omitted.

>Go has exactly the same issue. But with exceptions at least you can group multiple statements together and handle them with one catch block. With Go you have to use multiple if blocks to get the same semantics. Go does not suffer from this issue at all. I am not talking about flattening from the call hierarchy, I am talking about flattening the try scope itself. (In case it isn’t obvious: in Go you’d be forced to se…

> But it results in still less cumbersome code, since you only need scoping for the error handling portions.) There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks. There is a meaningful difference in cumbersomeness between what Go has today and "try foo(try bar())". Which is why it's so unfortunate that the community killed the try proposal. > But forgetting…

> There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks

As demonstrated by the sibling comment to mine, this is wrong.

> In practice programs written in languages with [exceptions] tend to have better error diagnostics than Go programs.

Anyone who's spent time on teams working in exception-oriented languages like C++ or Python knows this to be clearly false.

> Go is a more complex language than Java is overall

This is obviously wrong. One need look only at the GC landscape to disprove it.

Zero for three. Rust Evangelism Strike Force, go home.

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

#145

Post by wybiral » Wed, Jul 17, 2019, 1:56 AM UTC

jchw wrote: post #129

pcwalton wrote: post #106

Earlier quoted context omitted.

> But it results in still less cumbersome code, since you only need scoping for the error handling portions.) There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks. There is a meaningful difference in cumbersomeness between what Go has today and "try foo(try bar())". Which is why it's so unfortunate that the community killed the try proposal. > But forgetting…

>There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks. There is a meaningful difference in cumbersomeness between what Go has today and "try foo(try bar())". Which is why it's so unfortunate that the community killed the try proposal. Object thing1; try { thing1 = doStuff(); } catch(SameException e) { // handle error 1 } try { return doOtherStuff(thing1); } c…

The fact that it allows for more nesting on a single line is a bug, not a feature, IMO.

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

#146

Post by sagichmal » Wed, Jul 17, 2019, 1:58 AM UTC

justinclift wrote: post #101

baby wrote: post #66

Earlier quoted context omitted.

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…

Packages extensively using reflect + interfaces together can be a bit of a pain to work through. :/

Absolutely. But those are clear code smells. Any org with competent code review would flag them and kill them before they proliferated.

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

#147

Post by Zenst » Wed, Jul 17, 2019, 1:58 AM UTC

I hope somebody submits a "Do" and a "Do Not" amendment. Think of Yoda.

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

#148

Post by sagichmal » Wed, Jul 17, 2019, 1:59 AM UTC

pcwalton wrote: post #78

I suspected this was coming, and it's unfortunate. If Go had implemented try, then in a year everyone would be happy using it and the controversy would have died down. I've seen this happen before. Unfortunately, the community that has sprung up around Go is more or less opposed to new language features on principle.

Rust Evangelism Strike Force, please troll elsewhere.

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

#149

Post by Arnavion » Wed, Jul 17, 2019, 2:01 AM UTC

MaulingMonkey wrote: post #131

Arnavion wrote: post #111

Earlier quoted context omitted.

>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. Bu…

>`?` uses the `From` trait which means you often don't need `.map_err`.

1. `From` is a global solution to a local problem. All `std::io::Error` must necessarily be converted to the same enum variant regardless of what caused them. Failing to open a file and failing to write to a network socket will create the same variant.

2. `From` does not have access to context anyway. A `From` is not going to know that the error was hit specifically when "parsing the /etc/foo.conf file", and a `From` is not going to know the error was hit when "parsing the bar field of the /etc/foo.conf file because it is set to `baz` which is not an integer".

>as long as your error types implement std::error::Error, you shouldn't need an explicit .map_err to box them:

This only works when you want your function to return `Box` itself without any additional context. The conversation was about needing to add context like in the golang example.

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

#150

Post by mythz » Wed, Jul 17, 2019, 2:01 AM UTC

jchw wrote: post #61

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…

>So long as we can all agree that it feels super bad, I guess this is fine. Actually, I don't think everyone agrees it feels super bad. I personally like having all of my error handling be explicit, painfully explicit even. >approaches the Java world back with checked exceptions where principle trumped ergonomics. I also have to disagree here. To me, checked exceptions are the worst of both worlds. Here you have addi…

> Go doesn't even really force you to check your errors, it just makes it harder to accidentally not check them. Like:

I dislike it because it does the opposite, it makes it too easy to accidentally continue execution when there is an error:

    doThing(); // Error
    doOtherThing();

Which isn't possible with Exceptions.

The only thing that would signal that error handling is missing is the absence of boilerplate to handle it, which is an ugly UX for a language to rely on esp given there's no indication from scanning code that all methods that return errors are handled.