4 ms·
> ...functions don't declare what kind of errors they return. We've gone down this route with Java and my conclusion is that declaring the kind of errors a fun
by klodolph 5y ago
> ...functions don't declare what kind of errors they return.
We've gone down this route with Java and my conclusion is that declaring the kind of errors a function returns is, for most users, just a pain.
https://www.artima.com/articles/the-trouble-with-checked-exceptions https://www.artima.com/articles/the-trouble-with-checked-exc...
My experience with Go is that decent libraries only have a small number of error return types, and then forward or wrap errors from libraries that they use. You can use errors.Is(), errors.As(), errors.Unwrap() to figure things out as necessary.
- hota_mazi 5y agoIt's a pain because it forces users to consider and code against error paths. Just like putting on a seat belt is a pain. Both are pains that are worth having because they help you create robust software. The ways in which a function can fail should absolutely be part of its signature, and if these are recoverable, the compiler should refuse to build until you either handle these errors or pass them on to the caller.
- bsder 5y ago> The ways in which a function can fail should absolutely be part of its signature The problem with that is that a downstream library gets welded to the specific errors it can throw and can't evolve. So, what everybody will do is generate the most generic "Error" possible so that the signature never needs to change. That is NOT an improvement.
- kinjba11 5y agoI think there's a nice middle ground. For instance, in Swift a function can indicate that it throws, which is better than nothing. func canThrowErrors() throws -> String func cannotThrowErrors() -> String