Exploring Error Handling Patterns in Go

Re:Exploring Error Handling Patterns in Go by trisiak on Saturday August 18, 2018 @11:15PM (#17792365)

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.)

[ Parent | on HN ]

Re:Exploring Error Handling Patterns in Go by Groxx on Saturday August 25, 2018 @02:41PM (#17841946)

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.

[ Parent | on HN ]