4 ms·

I meant finding it in the context of a coder who writes a function. It's hard to identify which expression and statements can cause exceptions and effectively s

I meant finding it in the context of a coder who writes a function. It's hard to identify which expression and statements can cause exceptions and effectively short-circuit your function. In contrast to explicit errors-returned-as-values. (Panics of course can cause similar thing in Go but that's the reason why they should rarely be recovered and not used as a value propagation mechanism.)

Groxx 8y ago
Is that any worse than the ambiguity in e.g. code like this? func thing(arg) { otherThing(arg) // does this return an error you're ignoring? } It even has a similar problem, where void returns -> err returns on code changes are not visibly discoverable (similar to a newly-throwing func). Granted, you could turn this into a compiler error. But it's not currently. --- Anyway. Given that so many not-prevented-by-the-typesystem operations panic, I don't think it's reasonable to assume that any func call will not panic, especially not in the future since they may change. So you already have to program with `defer` to maintain your invariants, which is exactly the same as with exceptions, except you now have to deal with both possibilities for nearly every func.