3 ms·
IME, returning a "stringly-typed" error is only wrong if you don't provide enough context in the returned error message. You can describe what you were doing as
by kitd 4y ago
IME, returning a "stringly-typed" error is only wrong if you don't provide enough context in the returned error message. You can describe what you were doing as an error message and pass it back up the stack, each layer adding their own context, ie what they were trying to do to what. At the top you (should) get a pretty complete picture of what went wrong and why. I have found this reasonable and proportionate for most scenarios.
- cratermoon 4y agoThat's all well and good if all you want to do it propagate the error up the call stack until some code prints it, but that's not really handling the error, any more than if err != nil { return error } is. If the calling code needs to behave differently depending on the details of the error, the worst way to do that would be examine the message string. A robust system is going to respond very differently if, for example, the error is one that indicates retrying is worthwhile vs an error indicating that no amount of retrying will ever succeed.