12 ms·
I used to hate the repetitive nature of Go’s error handling until I was burned by bad/mysterious error messages in production. Now my error handling is not rep
by whstl 1y ago
I used to hate the repetitive nature of Go’s error handling until I was burned by bad/mysterious error messages in production.
Now my error handling is not repetitive anymore. I am in peace with Golang.
However I 100% get the complaint from the people who don’t need detailed error messages.
- DangitBobby 1y agoYou probably wouldn't have had the bad/mysterious error messages in production if they were just stack traces to begin with.
- danenania 1y agoStack traces are full of noise by comparison and don't have context added by the programmer at each frame. For me, Go error chains are much easier to work with. I can see the entire flow of the error at a glance, and can zero in on the relevant call in seconds with a single codebase search.
- DangitBobby 1y agoStack traces are not so long that you can't find the information you need in them, and actually just like go in some languages you can elect to add context to your stack trace (e.g. in python by raising an error from another error). My experience in go was opposite of yours. The original devs (who were long gone) provided no information at all at the error site and I felt lucky even to find the place in the code that produced the error. Unfortunately the "force you to handle errors" idea, while well intentioned, doesn't "force you to provide useful error handling information", making it worse than stack traces by default.
- danenania 1y agoYou're right that its usefulness is contingent on adding helpful context to errors. Without that, I might agree that stack traces are better.
- whstl 1y agoDepending on the framework stacks aren't be bad, they are just downright horrifying.