[IshKebab]

There are serious problems with exceptions.

1. It's often not clear which exceptions can be thrown from a function. I don't think many languages force you to list them all. In most languages it is a case of "this function can throw any exception it wants - read the source code (and of all the functions it calls) if you want to know which".

2. Adding context to exceptions is even more verbose than Go's error handling. In the video for this post for example, where they have fmt.Errorf() for each line that might fail you can easily add context like "opening file failed: ..." or "parsing file failed: ...". The equivalent with exceptions is a separate try/catch for every line! I've never seen anyone bother with that.

This seems like a bit of a flaw with the "handler" approach by the way. Rust's map_err() is a bit nicer.

[kemitche]

> It's often not clear which exceptions can be thrown from a function

Go 1 failed to solve that as well. "error" as an interface tells me nothing about what could go wrong with a function call. Go 2 is not looking like it will solve it either. I am happy with the proposals, but I know I'm still going to be looking at godocs and be forced to dig into source code to find out what error types actually come back, and hope they don't change from version to version.

[weberc2]

I agree with this. It would be great if we didn't have to give up any type safety with error returns. Even still, this is relatively minor when you remember that people write code in JS, Python, Ruby, etc with zero type safety.

[IshKebab]

This is true. However it is better in one big way - you at least know whether or not it will return an error at all.