3 ms·

I think history has absolutely shown that exceptions are not the best solution; they don't scale, as you point out. And I agree with Go that errors are values,

I think history has absolutely shown that exceptions are not the best solution; they don't scale, as you point out. And I agree with Go that errors are values, and should be passed around as such. Go basically tells us that errors are as really important — they should be in your face and handled by the caller. And then it goes ahead and makes it a second-class citizen that is really awfully laborious to work with. Why not make error-handling a first-class construct? Most code needs to just pass the error on to the caller, for example. Go would benefit from an easy way to just "bounce" the error off to the caller. Something like my naive, hypothetical macro in my previous comment. Some sum-type-based solution like Rust's Result enum would also have made the whole problem pretty much moot.

pcwalton 11y ago
> Go basically tells us that errors are as really important — they should be in your face and handled by the caller. And then it goes ahead and makes it a second-class citizen that is really awfully laborious to work with. Why not make error-handling a first-class construct? Not only that, it's very easy to just dump errors on the floor, which is why Golang needs tools like errcheck. For an easy example of this in practice (os.Setenv returns an error): https://github.com/search?l=go&q=os.Setenv&type=Code&utf8=%E2%9C%93 https://github.com/search?l=go&q=os.Setenv&type=Code&utf8=%E...
- lobster_johnson 11y ago
  Wow, people do this? I did have an error go unnoticed recently, but it was like this: v1, err := doStuff() if err != nil { return } var v2 MyStruct if value != nil { v2, err = doMoreStuff( some_param, different_param, one_more_params) } // ... use v1 and v2 err = doYetMoreStuff() I didn't catch the orphan err because I absent-mindedly focused on the parameter list to doMoreStuff() and just didn't see it. But I find it frustrating that Go will, on the one hand, angrily refuse to compile a program where a variable is unused, but on the other it will happily accept a program where a value is never used. Isn't that potentially as bad? I'd rather have it complain and force me to assign to _ if I really wanted to discard it.
rdtsc 11y ago
> I think history has absolutely shown that exceptions are not the best solution; Good point but exceptions or explicit handling (even with sum-type like in Rust) are not the only ways. There is also the crash-and restart way, Go has some with panic, Rust, Erlang is probably king here, can do it with OS processes as well. That of course, has to be handled well by the runtime, so either no shared memory so corruption doesn't spread arbitrarily throughout the application or provable compile time checking (like Rust).

pcwalton 11y ago

> Go basically tells us that errors are as really important — they should be in your face and handled by the caller. And then it goes ahead and makes it a second-class citizen that is really awfully laborious to work with. Why not make error-handling a first-class construct? Not only that, it's very easy to just dump errors on the floor, which is why Golang needs tools like errcheck. For an easy example of this in practice (os.Setenv returns an error): https://github.com/search?l=go&q=os.Setenv&type=Code&utf8=%E2%9C%93 https://github.com/search?l=go&q=os.Setenv&type=Code&utf8=%E...

lobster_johnson 11y ago
Wow, people do this? I did have an error go unnoticed recently, but it was like this: v1, err := doStuff() if err != nil { return } var v2 MyStruct if value != nil { v2, err = doMoreStuff( some_param, different_param, one_more_params) } // ... use v1 and v2 err = doYetMoreStuff() I didn't catch the orphan err because I absent-mindedly focused on the parameter list to doMoreStuff() and just didn't see it. But I find it frustrating that Go will, on the one hand, angrily refuse to compile a program where a variable is unused, but on the other it will happily accept a program where a value is never used. Isn't that potentially as bad? I'd rather have it complain and force me to assign to _ if I really wanted to discard it.

rdtsc 11y ago

> I think history has absolutely shown that exceptions are not the best solution; Good point but exceptions or explicit handling (even with sum-type like in Rust) are not the only ways. There is also the crash-and restart way, Go has some with panic, Rust, Erlang is probably king here, can do it with OS processes as well. That of course, has to be handled well by the runtime, so either no shared memory so corruption doesn't spread arbitrarily throughout the application or provable compile time checking (like Rust).