Is appropriate return a Enum Type Error?

[ZENOTME]

I find that in some case, function may not appropriate to return a enum type error, e.g.

/// Create a cast expr over `child` to `target` type in `allows` context.
pub fn new_cast(
    child: ExprImpl,
    target: DataType,
    allows: CastContext,
) -> Result<ExprImpl> 

If we look at the implementation of this function we will find that it only return a type of error BindError::("child type can't cast to target type"). But for the user of this function, if he want to process this error, he have to consider it as all kinds of error.

So in case like this, return as a more specified error like Result<ExprImpl,CastError> or even Result<ExprImpl,String> rather than a enum type error will better?🤔

there is a related issue #4077 to introduce per-crate error type.

But I think for simple function like new_cast, we can return a more fine-grained error so that user can process it more flex and easier. And we can covert it to per-crate error or more coarse grained error type in a more complex function. e.g.

pub fn new_cast(
    child: ExprImpl,
    target: DataType,
    allows: CastContext,
) -> Result<ExprImpl,String>

pub fn split_scan_range(...) -> Result<ExprImpl,RwError> {
    ...
    match new_cast {
        ...
        Err(error) => {
            ...do some process 
            // covert it to a more coarse grained error.
            return Err(BindError(error))
        }
    }
}

[BugenZhao]

+1 for a more specified error type of CastError where we can put more context in it. By impl From<CastError> for SuperError, we can also make the caller throw it seamlessly with ? if it's not interested.

[xxchan]

Generally speaking, I think more fine-grained return type is always better. Another example is returning concreate expr/plan type instead of ExprImpl/PlanRef.

However, regarding the overall design for error types, sometimes it might be unnecessary to define too many concrete error types. But when we have the need to handle a specific type of error, I guess it's ok to add one 🤔. Btw this topic is too lengthy and our error is not very clean, so ...

FWIW a reference: https://nrc.github.io/error-docs/error-design/error-type-design.html