2 ms·
that'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 de
by angra_mainyu 3y ago
that'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.