about errors usage about go-micro

[asim]

What do you define as a business error? This is a good point though and its come up multiple times. I think some want to be able to define which errors are appropriate for blacklisting while others define those "business" level errors in the Response.

I look at something like the Google APIs and see that more feature rich errors are returned within the response itself.

It might be that we change blacklisting to a predefined set of errors such as timeouts and internal server error.

[xujinzheng]

How about add error namespace or error level in Error struct ?

type Error struct {
    Namespace string `json:"namespace"`
    Id        string `json:"id"`
    Code      int32  `json:"code"`
    Detail    string `json:"detail"`
    Status    string `json:"status"`
}

type Error struct {
    Level  int32 `json:"level"`
    Id     string `json:"id"`
    Code   int32  `json:"code"`
    Detail string `json:"detail"`
    Status string `json:"status"`
}

if the namespace is system, then the micro framework will known some system errors happened.
or
if the level > 1 (internal=0, service=1, business=2), micro will ignore this error.

Our team currently using the errors package of http://github.com/gogap/errors, and we define errors as following

define errors

const (
    FundsErrNamespace = "FUNDS"
)

var(
    ErrIDCardTypeNotMatch = errors.TN(FundsErrNamespace, 82022, "user id card type does not match, id: {{.cardId}}")
)

use errors

// business logics
err=ErrIDCardTypeNotMatch.New(errors.Params{"cardId":"ABC12345"})
return

whether errors is "system" or "business", we will known the error namespace.

[asim]

Nothing expects that a go-micro/errors.Error be passed in so its difficult to make that assumption and define namespace or levels. It's a helpful package for defining more verbose errors if you want it, but its optional.

For the time being you have two options. Either you can define your business level errors as part of the response or create a selector that checks these errors differently.

[xujinzheng]

We will create a private selector for this issue, so ours developer will not care about errors usage .Thanks for your response.

[asim]

No problem.