Explore new error define pattern
Opened this issue · 0 comments
jiacai2050 commented
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.