3 ms·
I find stack traces to contain more noise and less signal than the error messages I see in Go. So the idea that exceptions with stack traces give you “both thin
by klodolph 4y ago
I find stack traces to contain more noise and less signal than the error messages I see in Go. So the idea that exceptions with stack traces give you “both things for free” doesn’t match my experience. I have professional experience in both software engineering and operations for apps written in both styles—from my experience, using exceptions makes it easier to write the code, and harder to diagnose errors in the running application.
- tsimionescu 4y agoSure, well crafted error traces will always beat automatically generated stack traces. However, in my experience debugging both local and customer issues based on logs, exceptions are, say, 80% of the way there, and they neither pollute your code nor leave you with 0 information if someone was lazy or in a hurry to ship something. Personally, I feel that what exceptions with stack traces get you is going to be the best trade-off between nice error messages in logs VS amount of effort in code spent to detail error paths. Of course, this doesn't have to be a 100% trade-off, and exceptions still allow you to add extra context whenever you feel it is necessary. Even if you decide to do it 100% of the time, they still act as an excellent safety net, making sure that you can't forget about an error, and need not be more verbose than if err!=nil checks or matches on the Result type (though I admit they do tend to be more verbose in most languages, requiring an extra block for try to be introduced).