You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 16, 2021. It is now read-only.
I have a possibly unusual use case which I don't think failure handles. I'm not sure if it should be handled by failure or if there's a good solution anyway, but I'd like to share the use case anyway.
I'm loading configuration and the running some verification on it. If the verification doesn't pass, I want to return an error and not load it.
However, there might be multiple things wrong with the configuration. So, conceptually, the top-level error („The configuration is broken“) has multiple parallel causes. There doesn't seem to be a way to express that using the „usual“ traits and the caller needs to try downcasting the error to the specific type to be able to extract the Vec<Error> from inside, representing all the smaller errors in there. I don't think this is a convenient API to expose, but I'm not entirely sure what would be.
The text was updated successfully, but these errors were encountered:
We have our our custom trait to express structured info about an error (location where validation error happened, code of an error, etc), which allows for multiple "causes". Then, we have to downcast to every possible concrete error type we have to get to that trait.
We also scan the error chain via cause (iter_chain on failure::Error), which makes the whole contraption quite brittle (because once we arrive at an error with "multiple causes", this chain would break -- we won't be following cause anymore).
Hello
I have a possibly unusual use case which I don't think
failure
handles. I'm not sure if it should be handled by failure or if there's a good solution anyway, but I'd like to share the use case anyway.I'm loading configuration and the running some verification on it. If the verification doesn't pass, I want to return an error and not load it.
However, there might be multiple things wrong with the configuration. So, conceptually, the top-level error („The configuration is broken“) has multiple parallel causes. There doesn't seem to be a way to express that using the „usual“ traits and the caller needs to try downcasting the error to the specific type to be able to extract the
Vec<Error>
from inside, representing all the smaller errors in there. I don't think this is a convenient API to expose, but I'm not entirely sure what would be.The text was updated successfully, but these errors were encountered: