4 ms·
What shortcuts would you recommend? The pattern itself as written above is rather useless. What you end up with is a call 3 libraries deep that returns nothin
by silisili 5y ago
What shortcuts would you recommend?
The pattern itself as written above is rather useless. What you end up with is a call 3 libraries deep that returns nothing but "EOF", and you have no idea what happened. In practice, you should really wrap every error return in a message and/or with a callstack. If the shortcut method can a) accomplish that, and b) avoid everything being nested, like try/except tends to do, I think I'd be more interested in the concept.
- morelisp 5y agoPlease no allocations hidden in the short syntax. I use `errors.WithMessage` / `fmt.Errorf` with `%w` often within my application's main execution flow, but I don't need a stack trace attached to every missing file, parse failure, or connection reset.
- silisili 5y agoApologies, to be more precise, my team wraps every error in a filename/line number pair, not an entire stacktrace.
- morelisp 5y agoWhat 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.
- dullgiulio 5y agoNo shortcuts. Errors reach end users, and they cannot read stack traces. Every shortcut makes for bad errors, bad troubleshooting and unhappy users. Errors document code (you literally write, in English, what you were trying to do but failed, at each level of your program.) Errors report to the user the clear intent that failed and why. Errors are a huge differentiator in quality. There is no shortcut to quality.
- cy_hauser 5y ago> Errors reach end users, and they cannot read stack traces. In general, users don't care about errors or stack traces. They don't want errors of any kind. As a developer I want users reporting errors, which can include a dense stack trace, so I can get the error and an explanation of what they were doing when the error happened. I'm more for making my life easier than worrying about what a user sees.
- lalaithion 5y agoI don't actually mind writing the above and adding context, but let's brainstorm some syntax that does the same thing without being verbose. How about something like: $variable1 := try $function_call_which_returns_two_values except $variable2: $expression_which_has_error_type which is automatically desugared to $variable1, $variable2 := $function_call_which_returns_two_values if $variable2 != nil { return ($zero_values_for_other_return_types, )* $expression_which_has_error_type }
- mseepgood 5y ago> let's brainstorm some syntax Don't forget to check if someone else already had the same idea: https://seankhliao.com/blog/12020-11-23-go-error-handling-proposals/ https://seankhliao.com/blog/12020-11-23-go-error-handling-pr...
- morelisp 5y agohttps://github.com/golang/go/issues/32437 https://github.com/golang/go/issues/32437
- lalaithion 5y agoThe try syntax proposed there and in other places returns the error unwrapped, which is a no-go for me. I wrap every error that I return from every function.
- encoderer 5y agoOh can I see how you do it?
- camkego 5y agoPlease share articles/blog posts! I would guess there are newer articles about best practices for Go error handling, other than the great articles by Dave Cheney. https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully https://dave.cheney.net/2016/04/27/dont-just-check-errors-ha...