Anyhow typed Errors?

[ioutro]

I really like the debug context that the anyhow Result type provides, but it lacks the error type and having to unwrap/downcast is pretty clunky. Is it possible to have typed Errors just like the standard Result type?

[mcmah309]

The current implementation of Error is a mirror of Rust anyhow crate's Error type, where it makes sense for Dart https://docs.rs/anyhow/latest/anyhow/struct.Error.html . I do agree I wish it could be more ergonomic when you want to actually inspect the error. The way I see it, a typed Error is not a possibility since that would defeat the purpose of Error being generic and would require Result to take an additional type, which would color the code. Here is how I handle Errors today:

Result x;
if(x case Err(:final err)){
    switch(err.rootCause().downcast().unwrap()){
        case ..:
        case ..:
    }
}

You could also iterate through with chain.
I think we can improve this though. I been thinking about introducing a downcastUnchecked<T extends Object> method. What that would allow you to do for this case is something like:

Result x;
if(x case Err(:final err)){
    switch(err.rootCause().downcastUnchecked()){
        case ..:
        case ..:
    }
}

Which may be a slight improvement.

That all said, I am open to suggestions on how to improve things.

[cds-reis]

Looking at this, could something like this method be added to the anyhow Result type?

void onType<T extends Object>(void Function(T error) f) {
    final rootCause = rootCause();
    if (rootCause is T) {
        f(rootCause);
    }
}

But I think the use for anyhow is at it's core to provide a simpler way to handle a result with the error information being displayed to you externally, eg: logging. So if you need to do something like retry based on error, it's better to use the base type.

[mcmah309]

Definitely useful if you want to inspect the root cause declaratively, but I'm struggling to think of an example of when you would want to do that. Usualy when I need to look at the root cause it is because I need to change my control flow based on the type of error, which I don't think that may be useful for. Do you have an example of when that could be useful?

I agree with most of what you said. I'd add though that I view anyhow as also allowing you to only care about the type of error when you want to, rather than coloring the code when you don't even know if you'll ever care about the type of error.

[mcmah309]

This might be useful.

Object? getRootCause() {
    if(x case Err(:final err)){
        return err.rootCause()._cause;
    }
   return null;
}

Used like

Result x;
switch(x.getRootCause()){ // or "if"

}

We'd be diverging from the original anyhow though, but I am open to it. Also, I don't like that name, so open to a better suggestion, just don't want it to be rootCause to avoid confusion with Errors rootCause.

[cds-reis]

Tbh I just don't like this because I don't believe it's the purpose of anyhow. It should be used when you don't care about what the error is, just that you can handle it safely without exceptions, adding context to it and logging in a very digestable format. When you need to inspect the errors for something, like getting a value out of it, you should use the base type, no need to complicate it.

I am using the anyhow result especially for internal mobile stuff, like remote-config, where it doesnt matter for the user what error happened, so we just log in our crashlytics. When an error matters for the user, we use the base type with a message from the backend in it's fields to show the user. Using the anyhow result for this is harmful, since you are adding uneeded complexity.

[mcmah309]

I think anyhow can be useful for situations like this.

Result<int,Exception1> func1();

Result<int,Exception2> func2();

Result<int,???> func3() => Result(($) {
    func1()[$];
    func2()[$];
});

Where func3 is not where I want to handle the error, but some parent of func3.

In an ideal world everything should be typed.

[mcmah309]

downcastUnchecked was Added. Closing due to lack of activity. Feel free to re-open if anything comes up.