4 ms·
See my response to a sibling. I wasn't clear; I was implicitly differentiating between these: 1. errors that can be handled locally (such as parsing; in other
by physicles 3y ago
See my response to a sibling. I wasn't clear; I was implicitly differentiating between these:
1. errors that can be handled locally (such as parsing; in other languages, these situations are often signaled with return values instead of exceptions)
2. errors that can't be handled locally (such as network errors; other languages use exceptions for these)
My argument was that worrying too much about error handling performance in #2 is premature optimization. 1ms is extreme, but the actual figure of capturing a call stack in Go -- several microseconds, by my benchmark -- puts it squarely in the "don't worry about it unless your code is performance-critical" category.
- kiitos 3y agoAn error is an error. The immediate caller is always responsible for detecting and handling errors in whatever way is appropriate for their calling context.