Skip to content

Commit f00e11e

Browse files
committed
slight tweeks
1 parent 5bf8917 commit f00e11e

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

Diff for: posts/inside-rust/2021-05-15-What-the-error-handling-project-group-is-working-towards.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -224,7 +224,7 @@ To resolve this issue, project error handling recently created a guideline for [
224224

225225
**An error type with a source error should either return that error via `source` or include that source's error message in it's own `Display` output, but never both.**
226226

227-
We figure the default will be to return errors via source. That way source errors can be reacted to via `downcast` when appropriate. This is particularly important for libraries that are changing existing public error types. For these libraries removing an error from `source` is a breaking change that isn't detected at compile time, making a major version bump likely insufficient. For more details check out our migration plan suggestion: [rust-lang/project-error-handling#44](https://github.com/rust-lang/project-error-handling/issues/44).
227+
We figure the default will be to return errors via source. That way source errors can be reacted to via `downcast` when appropriate. This is particularly important for libraries that are changing existing public error types. For these libraries removing an error from `source` is a breaking change that isn't detected at compile time, making a major version bump likely insufficient. Changing the `Display` output is also a breaking change, though a less dangerous one. To help with this we've drafted a suggested migration plan: [rust-lang/project-error-handling#44](https://github.com/rust-lang/project-error-handling/issues/44).
228228

229229
In coming up with this recommendation we had to figure out what the `Error` trait's primary role is in Rust. After discussing it with the library team we concluded that reporting should be treated as the primary role, and that reacting via `downcast` should come second when designing error types. Generally these needs are not in conflict, but it is possible for issues to come up. For example, when working with transparent error types that forward all methods to an inner error type. When these types follow this guideline the inner error type is skipped over and is never made available for `downcast`ing.
230230

0 commit comments

Comments
 (0)