3 ms·
It'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
by hota_mazi 5y ago
It'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