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

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

#81

Post by coldtea » Wed, Jun 05, 2019, 10:18 AM UTC

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…

>On the other hand, it might be a first step onto a slippery slope that ends with exceptions.

Or, you know, exceptions are the right slope, and the ad-hoc implementations of generics, error handling etc, is the slippery slope...

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

#82

Post by coldtea » Wed, Jun 05, 2019, 10:20 AM UTC

captncraig wrote: post #24

jerf wrote: post #6

Earlier quoted context omitted.

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.

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

Which is not bad at all.

In fact, it's closer to how e.g. Erlang works.

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

#83

Post by thisgoodlife » Wed, Jun 05, 2019, 10:24 AM UTC

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.

Do you think it would be better if it was called try_or_return?

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

#84

Post by panpanna » Wed, Jun 05, 2019, 10:27 AM UTC

Why not simply using a "?" the way kotlin and rust do?

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

#85

Post by tedunangst » Wed, Jun 05, 2019, 10:40 AM UTC

nmadden wrote: post #25

tedunangst wrote: post #15

Earlier quoted context omitted.

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.

Even with checked exceptions, you have to be careful. You may not want exceptions from every function you call to fly up to the caller.

    function X() throws Oops {
        okToFail(); // fine if this failure goes up
        unexpectedFailure(); // not fine to go up
    }

Unfortunately, once you tell the compiler its ok for exeptions to go up, that rule applies to the whole function.

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

#86

Post by [deleted] » Wed, Jun 05, 2019, 10:53 AM UTC

kstenerud wrote: post #72

If it were a keyword rather than a pseudo-function, I would support its addition. Psuedo-functions should not be allowed into the language, as they tend to have side effects that you wouldn't expect from a function call (such as returning from caller to grandparent). Some keyword that implies "return if error" so that you could then do: try v1, v2, v3 := someFunction() You could even make it a little bit smart, takin…

[deleted]

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

#87

Post by Alexendoo » Wed, Jun 05, 2019, 10:55 AM UTC

abvdasker wrote: post #33

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…

For 3., For use in defer the error return does have to be declared as you'd expect, in the examples it's done in the function signature

  func CopyFile(src, dst string) (err error) {
                                  ^^^
                                  here

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

#88

Post by jacques_chester » Wed, Jun 05, 2019, 11:18 AM UTC

arcticbull wrote: post #17

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

Exceptions are the opposite of a goto statement, basically a 'comes-from' statement. They violate the principal of least surprise in every way possible -- you may have no idea what type is being sent your way, where from or what to meaningfully do about it as a result. They often result in memory leaks in languages like C++ due to lack of destructor invocation. try() errors can only propagate to the caller. As such,…

> you may have no idea what type is being sent your way, where from or what to meaningfully do about it as a result.

How is this different from (a) errors bubbling up with a pile of concatenated strings as the only type information or (b) errors not bubbling up because someone decided they would never make a mistake?

The whole value of exceptions, to me, is consistency. The error is guaranteed to propagate in a consistent way up the stack. Static type analysis has a fighting chance of predicting what could ever propagate up the stack, whether checked or unchecked.

Trying to work out out what `err` might be in various situations is an exercise in forensic grepping. Trying to react intelligently and reliably to different types of error is an exercise in hoping nobody changes the error string.

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

#89

Post by randomdata » Wed, Jun 05, 2019, 11:27 AM UTC

pjmlp wrote: post #65

jchw wrote: post #41

Earlier quoted context omitted.

I don’t like exceptions at all. They do not make it obvious what is going on, I never am completely sure if I’m handling them right. When I want to throw an exception I’m often unsure which would be right, and sometimes your API can have multiple reasons to throw the same exception. Go error handling is not like that. But I can sure as hell say fairly that Go error handling is likely also not similar to what you did…

Yeah, until one realizes that most Go error handling is a mix of - Parsing error results inside strings - if .... else boilerplate - Underscore everywhere to silence them - Abuse from panic, aka exceptions in disguise If you want error handling without exception's guesswork, there are checked exceptions (used for the first time in CLU 1975), and result types (used for the first in ML in 1973) Both without the ceremon…

> exceptions in disguise

In disguise? I do not believe there is any mystery that panic/recover provide exceptions in Go. An exceptional case is exactly when you would want to use panic in a Go program. panic is provided in the language specifically to deal with exceptions.

If anything, it is other programming languages where exceptions are usuals in disguise.

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

#90

Post by pjmlp » Wed, Jun 05, 2019, 11:53 AM UTC

marcus_holmes wrote: post #76

pjmlp wrote: post #65

Earlier quoted context omitted.

Yeah, until one realizes that most Go error handling is a mix of - Parsing error results inside strings - if .... else boilerplate - Underscore everywhere to silence them - Abuse from panic, aka exceptions in disguise If you want error handling without exception's guesswork, there are checked exceptions (used for the first time in CLU 1975), and result types (used for the first in ML in 1973) Both without the ceremon…

You've read a lot of very bad Go code then, that doesn't follow any of the established practices for it. Your list there is almost a primer of "what not to do in Go", and is certainly not representative of the Go code in e.g. the standard library. I sense some frustration about the language... what happened to make you so anti-Go?

You mean like this standard library code?

https://go.googlesource.com/proposal/+/master/design/go2draf...

> I sense some frustration about the language... what happened to make you so anti-Go?

Go is C with GC and bounds checking, aka Limbo reborn with some Oberon-2 influence.

Already much better for our IT safety than sticking with C, still I kind of expected Google capable of producing Swift, Rust or TypeScript level of language design, given their pile of PhDs.