About Error Handling in Server

[krapie]

Description:

As I implementing some features, I noticed that it is quite cumbersome to add and handle error. I thought that there should be I best practice for go based gRPC server’s error handling, so I have researched few.

I’m leaving this issue to compare Yorkie’s error handling with other go based open source projects like etcd, kubernetes, promethous, grafana, etc.

First, I will compare Yorkie’s error handling with etcd, which also uses gRPC server as it’s modules.

In summary, etcd’s error handling structure looks like this:

• api
  • v3rpc/rpctypes
    • error.go : Creates custom error type variables using gRPC status and code.

      ErrGRPCRootUserNotExist = status.Error(codes.FailedPrecondition, "etcdserver: root user does not exist") 

• server
  • auth
    • store.go : ErrRootUserNotExist error is defined and used.

      ErrRootUserNotExist = errors.New("auth: root user does not exist") 

  • etcdserver/api/v3rpc

    • util.go : Handles error in server(togRPCError()). Imports several modules(store.go) in server, and maps modules’ error(ErrRootUserNotExist) to rpctypes.go's custom gRPC error(ErrGRPCRootUserNotExist) to convert to gRPC error.

      var toGRPCErrorMap = map[error]error{
          auth.ErrRootUserNotExist:     rpctypes.ErrGRPCRootUserNotExist,
          ...
      }

In Yorkie, error handling is done like this:

• server
  • backend
    • database.go : ErrProjectNotFound error is defined and used.

        ErrProjectNotFound = errors.New("project not found")

  • grpchelper

    • status.go : Handles error in server(toStatusError()). Imports several modules(database.go) in server, and maps modules’ error(ErrProjectNotFound) directly to gRPC error to convert to gRPC error.

      var errorToCode = map[error]codes.Code{
          database.ErrProjectNotFound:  codes.NotFound,
          ...
      }

The differences between the two is that there are custom gRPC error type variable defined in etcd’s api/types using status.error(). It looks like the overall error handling structure is almost the same except there are several api versions in etcd so it is nested with api versions.

To conclude, etcd seems to redefine error in api to clarify and organize all the errors that needs to be sent to client.

(I will add comparison on other open sources like K8s and Prometheus in further updates)

Why:

It is quite cumbersome to add and handle error on implementing new features.

Therefore, it will be good to introduce best practice for go based gRPC server’s error handling by referencing other go based open source projects like etcd, kubernetes, promethous, grafana, etc.

[hackerwins]

Related to #199.

[hackerwins]

Currently, the server delivers detailed error codes that occur to the client(#927). I'll close this issue for now and reopen it as needed.