3 ms·
> I have seen experienced programmers doing this pattern again and again and they are really convinced that it is helpful and consistent. In a nutshell, this i
by cwillu 3y ago
> I have seen experienced programmers doing this pattern again and again and they are really convinced that it is helpful and consistent.
In a nutshell, this is why I hate working in go. While I'm sure your code, dear hn golang fan, doesn't suffer from this, much of the go code I've had to deal with extends the principle of “unaware of many common failure modes and swallow them into the exit code” to every function.
- angra_mainyu 3y agothat's strange, I've been working professionally in Go for years and two things happen: 1) what are exceptions in many languages are plain errors in Go 2) a defer-recover block is usually put at the very top of a risky call This covers 99% of sources of panics. Now, the one that truly does mess you up is when it comes from CGO/calling out to C. That will tear your application and there is nothing you can do about it.
- cwillu 3y agoI wish they paniced. I'm talking about trees of function calls with variations on “err = thing(); if err: return err” multiple times in a function, so receiving an error code in the root function tells you very little about what went wrong or where it went wrong.
- gpderetta 3y agoExactly! Throwing away the call stack before deciding how to handle the error is not ideal.
- angra_mainyu 3y agoI've honestly never needed it when dealing an error, the fact that errors are handled near where they occur means a stack is rarely needed. If you bubble up errors a lot then errors.Is/As is made for that purpose. You really only care about a stack trace with a panic. In anycase, runtime.Stack() iirc should return the stack. But this sounds more like trying to write other languages in Go rather than writing in Go.