3 ms·
What is the (moral or performance) difference between wrapping every error you return anywhere with a filename/lineno pair, and a stack trace? If anything, the
by morelisp 5y ago
What is the (moral or performance) difference between wrapping every error you return anywhere with a filename/lineno pair, and a stack trace? If anything, the stacktrace proper probably only needs to allocate once, at the lowest level.
- silisili 5y agoThe specifics of it are deep enough in runtime that I've never actually looked, but it's designed as a chain to return a specific caller - it looks like - _, file, line, _ := runtime.Caller(2) locTxt := fmt.Sprintf(" (at %s:%d)", filepath.Base(file), line) I think if the above on errors became a performance concern, I'd heavily rethink what I considered an error. But, it is also possible the systems we've designed are miles apart in function and philosophy.
- morelisp 5y agoYeah, this is fine for like "unable to contact database server" or "kafka producer timeout" where you're gonna terminate a large portion (or all) of the application at a much higher, removed level. "Lifecycle" stuff. But if you make the short syntax do something like this, it's gonna get used for hundreds of library's equivalents of `Atoi` or `ParseQuery`. I don't need line annotations on my `http.ResponseWriter#Write` timeouts, they're slow enough already. (And if you are going to do it - really, just attach the whole stack trace then and there, it will probably be faster.)
- mariusor 5y agoI do this based on build tags for dev vs. production environments. In dev I attach the stacktrace to my errors, in prod I do not.