|
18 | 18 | //! |
19 | 19 | //! ```toml |
20 | 20 | //! [dependencies] |
21 | | -//! fail = "0.3" |
| 21 | +//! fail = "0.4" |
22 | 22 | //! ``` |
23 | 23 | //! |
24 | 24 | //! Now you can import the `fail_point!` macro from the `fail` crate and use it |
|
191 | 191 | //! |
192 | 192 | //! ```sh |
193 | 193 | //! $ FAILPOINTS=read-dir=return cargo run --features fail/failpoints |
194 | | -//! Compiling failpointtest v0.1.0 (/home/brian/pingcap/failpointtest) |
| 194 | +//! Compiling failpointtest v0.1.0 |
195 | 195 | //! Finished dev [unoptimized + debuginfo] target(s) in 2.38s |
196 | 196 | //! Running `target/debug/failpointtest` |
197 | 197 | //! Error: Custom { kind: PermissionDenied, error: StringError("error") } |
|
205 | 205 | //! That's the basics of fail points: defining them with `fail_point!`, |
206 | 206 | //! configuring them with `FAILPOINTS` and `fail::cfg`, and configuring them to |
207 | 207 | //! panic and return early. But that's not all they can do. To learn more see |
208 | | -//! the documentation for [`cfg`](fn.cfg.html) and |
| 208 | +//! the documentation for [`cfg`](fn.cfg.html), |
| 209 | +//! [`cfg_callback`](fn.cfg_callback.html) and |
209 | 210 | //! [`fail_point!`](macro.fail_point.html). |
210 | 211 | //! |
211 | 212 | //! |
212 | 213 | //! ## Usage considerations |
213 | 214 | //! |
214 | 215 | //! For most effective fail point usage, keep in mind the following: |
215 | 216 | //! |
216 | | -//! - Failpoints are disabled by default and can be enabled via the `failpoints` |
| 217 | +//! - Fail points are disabled by default and can be enabled via the `failpoints` |
217 | 218 | //! feature. When failpoints are disabled, no code is generated by the macro. |
218 | 219 | //! - Carefully consider complex, concurrent, non-deterministic combinations of |
219 | 220 | //! fail points. Put test cases exercising fail points into their own test |
|
0 commit comments