Skip to content

Commit baaec7e

Browse files
committed
Add a note about the Error blanket impl
Signed-off-by: Nick Cameron <[email protected]>
1 parent 8aaedb4 commit baaec7e

File tree

1 file changed

+3
-1
lines changed

1 file changed

+3
-1
lines changed

text/0000-dyno.md

+3-1
Original file line numberDiff line numberDiff line change
@@ -100,7 +100,7 @@ pub mod error {
100100
}
101101
}
102102

103-
impl dyn Error {
103+
impl dyn Error + '_ {
104104
...
105105
pub fn get_context_ref<T: ?Sized + 'static>(&self) -> Option<&T> {
106106
crate::provide_any::request_by_type_tag::<'_, tags::Ref<T>>(self)
@@ -111,6 +111,8 @@ pub mod error {
111111

112112
`get_context_ref` is added as a method on `Error` trait objects (`Error` is also likely to support similar methods for values and possibly other types, but I will elide those details), it simply calls `provide_any::request_by_type_tag` (we'll discuss this function and the `tags::Ref` passed to it below). But where does the context data come from? If a concrete error type supports backtraces, then it must override the `provide_context` method when implementing `Error` (by default, the method does nothing, i.e., no data is provided, so `get_context_ref` will always returns `None`). `provide_context` is used in the blanket implementation of `Provider` for `Error` types, in other words `Provider::provide` is delegated to `Error::provide_context`.
113113

114+
Note that by adding `provide_context` with a default empty implementation and the blanket `impl` of `Provider`, these changes to `Error` are backwards compatible. However, this pattern is only possible because `Provider` and `Error` will be defined in the same crate. For third party users, users will implement `Provider::provide` directly, in the usual way.
115+
114116
In `provide_context`, an error type provides access to data via a `Requisition` object, e.g., `req.provide_ref::<Backtrace>(&self.backtrace)`. The type of the reference passed to `provide_ref` is important here (and we encourage users to use explicit types with turbofish syntax even though it is not necessary, this might even be possible to enforce using a lint). When a user calls `get_context_ref`, the requested type must match the type of an argument to `provide_ref`, e.g., the type of `&self.backtrace` is `&Backtrace`, so a call to `get_context_ref::<Backtrace>()` will return a reference to `self.backtrace`. An implementer can make multiple calls to `provide_ref` to provide multiple data with different types.
115117

116118
Note that `Requisition` has methods for providing values as well as references, and for providing more complex types. These will be covered in the next section.

0 commit comments

Comments
 (0)