[groestl]

Easy, just assume it throws. That's the case anyway. Thanks to panics, even in Go.

Edit: Also, there is no parallel control flow. Languages with exceptions have union-type return values, and every statement is implicitly followed by the equivalent of: if err!=nil return nil, err. The fact that in Go you have to type that makes Go cumbersome, not smart.

[jy3]

I'm not sure I understand the relationship between union-types and exceptions. You mean something like <Result, ErrorData>? Could you expand on that?

> Thanks to panics, even in Go.

Fortunately, for some reason Go developers don't use panic like exceptions and recover them at library boundaries.

[groestl]

<Result, ErrorData>

Yes, exactly like that. In real world programs, every function might fail, even the simplest ones (stack overflow, out of memory, interrupts, etc). No information is gained by declaring a specific function might fail. Also it's almost certainly a lie to declare: this function will never fail. So if every function might fail, why not just produce a union type <Result|ErrorData> for every function return type. Also, lets automatically check for the error case after each nested invocation, and cleanly unwind the stack (returning ErrorData again) on failure. This makes 95% error handling code go away. The ErrorData type uses a special return keyword ("throw"), and in rare cases, errors need to actually be handled, so the union's ErrorData type is exposed to the user code with additional primitives (catch). On all the code in between, the ErrorData type is just hidden behind the scenes.

[cube2222]

Not really, in all the years I've been writing Go, only one library used panics for error handling.

Usually if something panics you don't want to handle it. (Other than at the http handler level, where you can just throw an InternalServerError and log the panic)

First and foremost, you can usually assume libraries won't panic, though it would be nice to have a tool (grep) to check for explicit panics.

[groestl]

If something "errors", you usually don't want to handle it either. Other that at the http handler level.

[cube2222]

Actually, you often do. That's the point really. You should decide if it's an operation you might want to retry, you might also want to just flat out error and do nothing more, maybe you want to provide degraded functionality, like provide some default answer.

I think errors as values cause you to always think about this, which makes you handle errors in a more sensible way, instead of just bubbling up. Sure, 90% of situations you will bubble up, but in my opinion it's still worth it.

[groestl]

You basically said so in your last paragraph, and I agree it's a tradeoff, I just want to reiterate that in my experience, bubbling up and retrying/degrading/failing at the top level (system boundary, client side) makes for a robust (distributed) system you can reason about. Having hundreds of easter eggs in the project where somebody tried to do something smart when encountering an error seems more like a nightmare scenario to me. Old Java enterprise applications are filled with this, and they are rightfully frowned upon. Checked exceptions are the culprit.