Explore new error define pattern

[jiacai2050]

Describe This Problem

Currently, we rely on snafu to define/handle errors, there are some issues with current usage.

First, let me explain how error is defined within horaedb.

• Every module has an an Enum-style error, which contains detailed error information
• When convert error from one module to another, we use context to do the heavy work.

This sounds like a good design pattern, but it become very verbose in practice. Some example:

• Every module force an Enum-style error, which contains too many unnecessary item.
• When consume error from module A in module B, we usually box them, since we don't want to define too many error item in module B. This make the error opaque again...

All in all, enum based error design should be limited in some way.

Proposal

Error details should be opaque, if caller want to program based on it, the error provide a pub fn kind() -> ErrorKind.

In this way, we can better to encapsulate error details, and make error small.

Additional Context

• https://matklad.github.io/2020/10/15/study-of-std-io-error.html
• https://www.unwoundstack.com/blog/rust-error-handling.html