On 2/18/21 4:01 AM, robert engels wrote: > But - the issue is that most of the time - for complex systems - the errors > cannot be handled where they are encountered - even in Go, most of the error > handling becomes boilerplate returning the error detected and expecting some > higher level to handle it.
Occasionally I think what could I add here at the points that you call boilerplate. However, I almost always add context at every level. The benefit is that I hardly ever have to pull out a debugger or even read the code aside from the failure point or stdlib code. The debugger is useful for more subtle issues, but a big, time waste, most of the time. You can also create test errors easily by wrapping with the recent changes. Wrapped errors act, in a way like exceptions. In fact, I log the latest test/wrapped error and any previous one in the chain. So that I may see any one provided by the stdlib as well as my own. What you are proposing doesn't match up with Gos ease of picking up and running with the language with good outcomes because exceptions are less likely to be handled than errors by most devs and also in most situations. It also doesn't marry up with the policy of trying to keep one way of doing things, for similar reasons. Isn't there a package, that you could use? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a4f5ba51-c704-9616-a8b9-c6a0bbad1bab%40gmail.com.
