|
24 | 24 | //! * error-chain is easy to configure. Handle errors robustly with minimal |
25 | 25 | //! effort. |
26 | 26 | //! * Basic error handling requires no maintenance of custom error types |
27 | | -//! nor the `From` conversions that make `?` work. |
| 27 | +//! nor the [`From`] conversions that make `?` work. |
28 | 28 | //! * error-chain scales from simple error handling strategies to more |
29 | 29 | //! rigorous. Return formatted strings for simple errors, only |
30 | 30 | //! introducing error variants and their strong typing as needed for |
|
40 | 40 | //! error-chain is based on the following principles: |
41 | 41 | //! |
42 | 42 | //! * No error should ever be discarded. This library primarily |
43 | | -//! makes it easy to "chain" errors with the `chain_err` method. |
| 43 | +//! makes it easy to "chain" errors with the [`chain_err`] method. |
44 | 44 | //! * Introducing new errors is trivial. Simple errors can be introduced |
45 | 45 | //! at the error site with just a string. |
46 | 46 | //! * Handling errors is possible with pattern matching. |
47 | 47 | //! * Conversions between error types are done in an automatic and |
48 | | -//! consistent way - `From` conversion behavior is never specified |
| 48 | +//! consistent way - [`From`] conversion behavior is never specified |
49 | 49 | //! explicitly. |
50 | | -//! * Errors implement Send. |
| 50 | +//! * Errors implement [`Send`]. |
51 | 51 | //! * Errors can carry backtraces. |
52 | 52 | //! |
53 | 53 | //! Similar to other libraries like [error-type] and [quick-error], |
54 | 54 | //! this library introduces the error chaining mechanism originally |
55 | | -//! employed by Cargo. The `error_chain!` macro declares the types |
| 55 | +//! employed by Cargo. The [`error_chain!`] macro declares the types |
56 | 56 | //! and implementation boilerplate necessary for fulfilling a |
57 | 57 | //! particular error-handling strategy. Most importantly it defines a |
58 | | -//! custom error type (called `Error` by convention) and the `From` |
| 58 | +//! custom error type (called [`Error`] by convention) and the [`From`] |
59 | 59 | //! conversions that let the `?` operator work. |
60 | 60 | //! |
61 | 61 | //! This library differs in a few ways from previous error libs: |
62 | 62 | //! |
63 | | -//! * Instead of defining the custom `Error` type as an enum, it is a |
64 | | -//! struct containing an `ErrorKind` (which defines the |
65 | | -//! `description` and `display_chain` methods for the error), an opaque, |
66 | | -//! optional, boxed `std::error::Error + Send + 'static` object |
67 | | -//! (which defines the `cause`, and establishes the links in the |
68 | | -//! error chain), and a `Backtrace`. |
69 | | -//! * The macro also defines a `ResultExt` trait that defines a |
70 | | -//! `chain_err` method. This method on all `std::error::Error + Send + 'static` |
| 63 | +//! * Instead of defining the custom [`Error`] type as an enum, it is a |
| 64 | +//! struct containing an [`ErrorKind`][] (which defines the |
| 65 | +//! [`description`] and [`display_chain`] methods for the error), an opaque, |
| 66 | +//! optional, boxed [`std::error::Error`]` + `[`Send`]` + 'static` object |
| 67 | +//! (which defines the [`cause`], and establishes the links in the |
| 68 | +//! error chain), and a [`Backtrace`]. |
| 69 | +//! * The macro also defines a [`ResultExt`] trait that defines a |
| 70 | +//! [`chain_err`] method. This method on all [`std::error::Error`]` + `[`Send`]` + 'static` |
71 | 71 | //! types extends the error chain by boxing the current |
72 | 72 | //! error into an opaque object and putting it inside a new concrete |
73 | 73 | //! error. |
74 | | -//! * It provides automatic `From` conversions between other error types |
75 | | -//! defined by the `error_chain!` that preserve type information, |
| 74 | +//! * It provides automatic [`From`] conversions between other error types |
| 75 | +//! defined by the [`error_chain!`] that preserve type information, |
76 | 76 | //! and facilitate seamless error composition and matching of composed |
77 | 77 | //! errors. |
78 | | -//! * It provides automatic `From` conversions between any other error |
79 | | -//! type that hides the type of the other error in the `cause` box. |
| 78 | +//! * It provides automatic [`From`] conversions between any other error |
| 79 | +//! type that hides the type of the other error in the [`cause`] box. |
80 | 80 | //! * If `RUST_BACKTRACE` is enabled, it collects a single backtrace at |
81 | 81 | //! the earliest opportunity and propagates it down the stack through |
82 | | -//! `From` and `ResultExt` conversions. |
| 82 | +//! [`From`] and [`ResultExt`] conversions. |
83 | 83 | //! |
84 | 84 | //! To accomplish its goals it makes some tradeoffs: |
85 | 85 | //! |
86 | | -//! * The split between the `Error` and `ErrorKind` types can make it |
| 86 | +//! * The split between the [`Error`] and [`ErrorKind`] types can make it |
87 | 87 | //! slightly more cumbersome to instantiate new (unchained) errors, |
88 | | -//! requiring an `Into` or `From` conversion; as well as slightly |
| 88 | +//! requiring an [`Into`] or [`From`] conversion; as well as slightly |
89 | 89 | //! more cumbersome to match on errors with another layer of types |
90 | 90 | //! to match. |
91 | | -//! * Because the error type contains `std::error::Error + Send + 'static` objects, |
92 | | -//! it can't implement `PartialEq` for easy comparisons. |
| 91 | +//! * Because the error type contains [`std::error::Error`]` + `[`Send`]` + 'static` objects, |
| 92 | +//! it can't implement [`PartialEq`] for easy comparisons. |
93 | 93 | //! |
94 | 94 | //! ## Declaring error types |
95 | 95 | //! |
|
98 | 98 | //! basis, such as per module. |
99 | 99 | //! |
100 | 100 | //! Assuming you are using crate-level error types, typically you will |
101 | | -//! define an `errors` module and inside it call `error_chain!`: |
| 101 | +//! define an `errors` module and inside it call [`error_chain!`]: |
102 | 102 | //! |
103 | 103 | //! ``` |
104 | 104 | //! # #[macro_use] extern crate error_chain; |
|
174 | 174 | //! be omitted if it is empty. |
175 | 175 | //! |
176 | 176 | //! This populates the module with a number of definitions, |
177 | | -//! the most important of which are the `Error` type |
178 | | -//! and the `ErrorKind` type. An example of generated code can be found in the |
| 177 | +//! the most important of which are the [`Error`] type |
| 178 | +//! and the [`ErrorKind`] type. An example of generated code can be found in the |
179 | 179 | //! [example_generated](example_generated/index.html) module. |
180 | 180 | //! |
181 | 181 | //! ## Returning new errors |
|
191 | 191 | //! } |
192 | 192 | //! ``` |
193 | 193 | //! |
194 | | -//! Introducing new error chains, with an `ErrorKind`: |
| 194 | +//! Introducing new error chains, with an [`ErrorKind`]: |
195 | 195 | //! |
196 | 196 | //! ``` |
197 | 197 | //! # #[macro_use] extern crate error_chain; |
|
205 | 205 | //! } |
206 | 206 | //! ``` |
207 | 207 | //! |
208 | | -//! Note that the return type is the typedef `Result`, which is |
| 208 | +//! Note that the return type is the typedef [`Result`], which is |
209 | 209 | //! defined by the macro as `pub type Result<T> = |
210 | 210 | //! ::std::result::Result<T, Error>`. Note that in both cases |
211 | | -//! `.into()` is called to convert a type into the `Error` type; both |
212 | | -//! strings and `ErrorKind` have `From` conversions to turn them into |
213 | | -//! `Error`. |
| 211 | +//! [`.into()`] is called to convert a type into the [`Error`] type; both |
| 212 | +//! strings and [`ErrorKind`] have [`From`] conversions to turn them into |
| 213 | +//! [`Error`]. |
214 | 214 | //! |
215 | 215 | //! When the error is emitted behind the `?` operator, the explicit conversion |
216 | 216 | //! isn't needed; `Err(ErrorKind)` will automatically be converted to `Err(Error)`. |
|
232 | 232 | //! ## The `bail!` macro |
233 | 233 | //! |
234 | 234 | //! The above method of introducing new errors works but is a little |
235 | | -//! verbose. Instead, we can use the `bail!` macro, which performs an early return |
| 235 | +//! verbose. Instead, we can use the [`bail!`] macro, which performs an early return |
236 | 236 | //! with conversions done automatically. |
237 | 237 | //! |
238 | | -//! With `bail!` the previous examples look like: |
| 238 | +//! With [`bail!`] the previous examples look like: |
239 | 239 | //! |
240 | 240 | //! ``` |
241 | 241 | //! # #[macro_use] extern crate error_chain; |
|
275 | 275 | //! # } |
276 | 276 | //! ``` |
277 | 277 | //! |
278 | | -//! `chain_err` can be called on any `Result` type where the contained |
279 | | -//! error type implements `std::error::Error + Send + 'static`, as long as |
280 | | -//! the `Result` type's corresponding `ResultExt` trait is in scope. If |
281 | | -//! the `Result` is an `Err` then `chain_err` evaluates the closure, |
282 | | -//! which returns *some type that can be converted to `ErrorKind`*, |
| 278 | +//! [`chain_err`] can be called on any [`Result`] type where the contained |
| 279 | +//! error type implements [`std::error::Error`]` + `[`Send`]` + 'static`, as long as |
| 280 | +//! the [`Result`] type's corresponding [`ResultExt`] trait is in scope. If |
| 281 | +//! the [`Result`] is an `Err` then [`chain_err`] evaluates the closure, |
| 282 | +//! which returns *some type that can be converted to [`ErrorKind`]*, |
283 | 283 | //! boxes the original error to store as the cause, then returns a new |
284 | 284 | //! error containing the original error. |
285 | 285 | //! |
286 | | -//! Calling `chain_err` on an existing `Error` instance has the same |
287 | | -//! signature and produces the same outcome as being called on a `Result` |
288 | | -//! matching the properties described above. This is most useful when |
289 | | -//! partially handling errors using the `map_err` function. |
| 286 | +//! Calling [`chain_err`][Error_chain_err] on an existing [`Error`] instance has |
| 287 | +//! the same signature and produces the same outcome as being called on a |
| 288 | +//! [`Result`] matching the properties described above. This is most useful when |
| 289 | +//! partially handling errors using the [`map_err`] function. |
290 | 290 | //! |
291 | | -//! To chain an error directly, use `with_chain`: |
| 291 | +//! To chain an error directly, use [`with_chain`]: |
292 | 292 | //! |
293 | 293 | //! ``` |
294 | 294 | //! # #[macro_use] extern crate error_chain; |
|
324 | 324 | //! # } |
325 | 325 | //! ``` |
326 | 326 | //! |
327 | | -//! The `Error` and `ErrorKind` types implements `From` for the corresponding |
| 327 | +//! The [`Error`] and [`ErrorKind`] types implements [`From`] for the corresponding |
328 | 328 | //! types of all linked error chains. Linked errors do not introduce a new |
329 | 329 | //! cause to the error chain. |
330 | 330 | //! |
331 | 331 | //! ## Matching errors |
332 | 332 | //! |
333 | 333 | //! error-chain error variants are matched with simple patterns. |
334 | | -//! `Error` is a tuple struct and its first field is the `ErrorKind`, |
| 334 | +//! [`Error`] is a tuple struct and its first field is the [`ErrorKind`], |
335 | 335 | //! making dispatching on error kinds relatively compact: |
336 | 336 | //! |
337 | 337 | //! ``` |
|
429 | 429 | //! # } |
430 | 430 | //! ``` |
431 | 431 | //! |
432 | | -//! The `Error` and `ErrorKind` types also allow programmatic access to these elements. |
| 432 | +//! The [`Error`] and [`ErrorKind`] types also allow programmatic access to these elements. |
433 | 433 | //! |
434 | 434 | //! ## Foreign links |
435 | 435 | //! |
436 | 436 | //! Errors that do not conform to the same conventions as this library |
437 | 437 | //! can still be included in the error chain. They are considered "foreign |
438 | 438 | //! errors", and are declared using the `foreign_links` block of the |
439 | | -//! `error_chain!` macro. `Error`s are automatically created from |
| 439 | +//! [`error_chain!`] macro. [`Error`]s are automatically created from |
440 | 440 | //! foreign errors by the `?` operator. |
441 | 441 | //! |
442 | 442 | //! Foreign links and regular links have one crucial difference: |
443 | | -//! `From` conversions for regular links *do not introduce a new error |
| 443 | +//! [`From`] conversions for regular links *do not introduce a new error |
444 | 444 | //! into the error chain*, while conversions for foreign links *always |
445 | 445 | //! introduce a new error into the error chain*. So for the example |
446 | | -//! above all errors deriving from the `std::fmt::Error` type will be |
447 | | -//! presented to the user as a new `ErrorKind::Fmt` variant, and the |
448 | | -//! cause will be the original `std::fmt::Error` error. In contrast, when |
| 446 | +//! above all errors deriving from the [`std::fmt::Error`] type will be |
| 447 | +//! presented to the user as a new [`ErrorKind`] variant, and the |
| 448 | +//! cause will be the original [`std::fmt::Error`] error. In contrast, when |
449 | 449 | //! `other_error::Error` is converted to `Error` the two `ErrorKind`s |
450 | 450 | //! are converted between each other to create a new `Error` but the |
451 | 451 | //! old error is discarded; there is no "cause" created from the |
|
455 | 455 | //! |
456 | 456 | //! If the `RUST_BACKTRACE` environment variable is set to anything |
457 | 457 | //! but ``0``, the earliest non-foreign error to be generated creates |
458 | | -//! a single backtrace, which is passed through all `From` conversions |
459 | | -//! and `chain_err` invocations of compatible types. To read the |
460 | | -//! backtrace just call the `backtrace()` method. |
| 458 | +//! a single backtrace, which is passed through all [`From`] conversions |
| 459 | +//! and [`chain_err`] invocations of compatible types. To read the |
| 460 | +//! backtrace just call the [`backtrace`] method. |
461 | 461 | //! |
462 | 462 | //! Backtrace generation can be disabled by turning off the `backtrace` feature. |
463 | 463 | //! |
464 | 464 | //! ## Iteration |
465 | 465 | //! |
466 | | -//! The `iter` method returns an iterator over the chain of error boxes. |
| 466 | +//! The [`iter`] method returns an iterator over the chain of error boxes. |
467 | 467 | //! |
468 | 468 | //! [error-type]: https://github.com/DanielKeep/rust-error-type |
469 | 469 | //! [quick-error]: https://github.com/tailhook/quick-error |
470 | 470 |
|
| 471 | +//! [`display_chain`]: trait.ChainedError.html#method.display_chain |
| 472 | +//! [`error_chain!`]: macro.error_chain.html |
| 473 | +//! [`bail!`]: macro.bail.html |
| 474 | +//! [`Backtrace`]: struct.Backtrace.html |
| 475 | +
|
| 476 | +//! [`Error`]: example_generated/struct.Error.html |
| 477 | +//! [`with_chain`]: example_generated/struct.Error.html#method.with_chain |
| 478 | +//! [Error_chain_err]: example_generated/struct.Error.html#method.chain_err |
| 479 | +//! [`cause`]: example_generated/struct.Error.html#method.cause |
| 480 | +//! [`backtrace`]: example_generated/struct.Error.html#method.backtrace |
| 481 | +//! [`iter`]: example_generated/struct.Error.html#method.iter |
| 482 | +//! [`ErrorKind`]: example_generated/enum.ErrorKind.html |
| 483 | +//! [`description`]: example_generated/enum.ErrorKind.html#method.description |
| 484 | +//! [`Result`]: example_generated/type.Result.html |
| 485 | +//! [`ResultExt`]: example_generated/trait.ResultExt.html |
| 486 | +//! [`chain_err`]: example_generated/trait.ResultExt.html#tymethod.chain_err |
| 487 | +
|
| 488 | +//! [`std::error::Error`]: https://doc.rust-lang.org/std/error/trait.Error.html |
| 489 | +//! [`Send`]: https://doc.rust-lang.org/std/marker/trait.Send.html |
| 490 | +//! [`Into`]: https://doc.rust-lang.org/std/convert/trait.Into.html |
| 491 | +//! [`From`]: https://doc.rust-lang.org/std/convert/trait.From.html |
| 492 | +//! [`PartialEq`]: https://doc.rust-lang.org/std/cmp/trait.PartialEq.html |
| 493 | +//! [`std::fmt::Error`]: https://doc.rust-lang.org/std/fmt/struct.Error.html |
| 494 | +//! [`.into()`]: https://doc.rust-lang.org/std/convert/trait.Into.html#tymethod.into |
| 495 | +//! [`map_err`]: https://doc.rust-lang.org/std/result/enum.Result.html#method.map_err |
471 | 496 |
|
472 | 497 | #[cfg(feature = "backtrace")] |
473 | 498 | extern crate backtrace; |
|
0 commit comments