Create an abstraction for Internal Errors vs Request Errors.

[robert-zaremba]

Summary

Most (if not all) errors created in the SDK don't have any semantic. This makes it hard (or even impossible) to define some logic for handling this kind of errors (example: sending them to some errors aggregator), printing, notifications.

Problem Definition

Explained above.

Proposal

Use a structures which implement the Error interface and are able to carry semantic information.

One option is to use the errstack library. Disclaimer: I'm an author of it and use it in many enterprise projects.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

We have the types/errors pkg that does exactly this. It carries ABCI information (if any) and implements the error interface. So what's missing?

[robert-zaremba]

Yes, types/errors looks good - but we need to to be more specific about what's the root of the error. For the moment we can't distinguish request errors from logic errors (when some assumption is broken) / internal errors (eg network error / DB error...).

So, either we make a small update the errors package, or change the type. I think update should work, and here is an idea:

We can add a new parameter to the New function, which will be an enum, and add it to the Error structure:

type ErrorType int
const (
  ReqError ErrorType = iota
  LogicError
  InternalError
)
func New(codespace string, code uint32, typ ErrorType, desc string) *Error {

If we want to make this not-breaking change, then we can add it as an optional argument (variadic argument) of New instead of having it in the middle.

[robert-zaremba]

Some background for this issue: #7166 (comment)

[alexanderbez]

Are there examples in other libraries that do this? I've never seen this convention in Golang. Typically, the error message and/or error type name provide all the context. In addition, we already have code and codespace, so why not stick with those?

[robert-zaremba]

Yes, this library will also work - we will just need to do small update to classify errors between internal and not internal. This can be done either by adding a new parameter to the New function, or exporting a function IsInternal which will do a big check using code. In general, many libraries are classifying errors: upspin, juju/errors, go-openapi/errors...

The main motivation is to enable smart reporting / monitoring. Enterprises usually don't want to report request errors internally. But they want to report / monitor for internal errors, local net IO errors etc...

[tac0turtle]

reopen if this is still relevant.