
With these fixes in place it will become easy to chain errors and report them completely and consistently.
#RUST DOWNCAST FULL#
This will work well with composition because the reporter from the outermost type will be used to format the full chain of errors.įor now we can't implement this method as described because impl Trait isn't allowed in return types on trait methods, but we're working to find a way to add this to the error trait backwards compatibly. We expect that derive macros may leverage this to customize error reporting format defaults. We want the return type here to be generic rather than hard coded to Report so that individual error types can provide their own report format if desired. We expect the report method will look something like this: fn report(&self) -> impl Display + '_ config" and has a source error which just prints "configįn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result ", error.report())

And we have an error type that just prints "invalid always errors, since we're just focusing on diagnostics We have a dummy implementation of load_config which expect("config is always valid and exists") loading the config will always succeed. We have a program that loads a config and expects that There are a couple of places this can happen, either when printing an error and forgetting to print sources, when returning an error from main, or when converting a recoverable error into a non recoverable error.

The first challenge we'd like to solve is that it's easy to lose context accidentally when reporting errors. There are technical challenges here to sort out so the final outcome may look rather different from our initial vision, so please don't assume any of this is final. But first we need to describe the main challenges we've identified.ĭisclaimer: This post is equal parts plan and aspiration. We've been iterating for a while now on some of the challenges that we see with error handling today and have reached the point where we want to describe some of the new changes we're working towards. This blog post is a follow up of our previous post detailing what we're working on now.
