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. Moved to a discussion. Feel free to re-open if anything comes up.

[tomwyr]

I was also disappointed by the context acting as result's error when I discovered anyhow. For me at least, the main advantage of having typed errors would be executing some control flow logic as usual, while also being able to attach error details to the flow that might not be desired to be exposed in the result itself.
Let's say, if I return an error result in response to an asynchronous http call because of some unexpected json data, I don't want to let that information be part of my domain layer. At the same, if my control flow reaches a point where the error is eventually handled, I want to still send that information to some logging service with the root cause, including json data that started the error "path" in my code.

[mcmah309]

As you may know, anyhow Result<T> is a typedef for Result<T,anyhow.Error>. A typedef is used for a few reasons:

• Compatible api for anywhere Result<T,F> is used and all extensions
• The base Result is a sealed class and sealed classes cannot be extended.

Therefore, I don't think there is anything we can do about the error type being the second type.

It is possible we could change the anyhow.Error signature to anyhow.Error<T extends Object>. Then in this package, or yourself, a different typedef like Result<T,E> = Result<T, anyhow.Error<E>> could be created. This would allow you to keep the power of anyhow, but still keep types.

A problem arises with this though. All context needs to be the same in this current implementation, since each error needs to know the parent errors type. So if your root is ExceptionA any added context needs to be ExceptionA. Adding another generic to try to specify a parents error type is not possible since it leads to an endless cycle. Therefore if this is not the desired effect, as it seems like, the current implementation would have to be reworked.

First lets visit why each call to context needs to be a new context/Error.
The problem comes when we reach async. Say we are working with streams and the Result goes to two different stream endpoints. At each endpoint and subsequent callstack we may add context, if we did use the current functionality, any added context would get jumbled. Also you may run into additional error's when handling the Result and may want to add that to the original Result as context.

We could have E just represent of its root and propagate that information. This may be breaking off the top of my head I'd have to explore.

All of this to say, it is possible, it would also be different from the original Rust anyhow crate. Open to suggestions as well.

Side: If you are looking for types and don't care about context. thiserror can take a small amount of boilerplate away.

[tomwyr]

I think to me typed errors and contexts are two different features that are not mutually exclusive (with my semi limited understanding of how Results work). For the contexts I wouldn't probably care about typing them, because they're more of a debug information that I might inspect at some point in code or during debugging.

That information could be passed around with results stored as an additional bit of data attached to it. That'd mean such an approach might require extending the result class or creating a base error type that the user's error types need to conform to. Which could, in turn, introduce some limitations or changes to the api of the Result type.

I see why you'd like to keep things simple and stick to the Rust's crate implementation. If typing errors isn't that important for someone's use case, anyhow in its current shape works just fine. Maybe I'll do some prototyping and try to see if this idea makes any sense.