|
35 | 35 | //! |
36 | 36 | //! fn parse_version(header: &[u8]) -> Result<Version, &'static str> { |
37 | 37 | //! if header.len() < 1 { |
38 | | -//! return Err("invalid header length");; |
| 38 | +//! return Err("invalid header length"); |
39 | 39 | //! } |
40 | 40 | //! match header[0] { |
41 | 41 | //! 1 => Ok(Version1), |
|
77 | 77 | //! // Use `or_else` to handle the error. |
78 | 78 | //! let bad_result: Result<int, int> = bad_result.or_else(|i| Ok(11)); |
79 | 79 | //! |
80 | | -//! // Convert to an `Option` to call e.g. `unwrap`. |
| 80 | +//! // Consume the result and return the contents with `unwrap`. |
81 | 81 | //! let final_awesome_result = good_result.ok().unwrap(); |
82 | 82 | //! ~~~ |
83 | 83 | //! |
84 | 84 | //! # Results must be used |
85 | 85 | //! |
86 | | -//! A common problem with using return values to indicate errors |
87 | | -//! is that it is easy to ignore the return value, thus failing |
88 | | -//! to handle the error. By possessing the `#[must_use]` attribute, |
89 | | -//! the compiler will warn when a `Result` type is ignored. This |
90 | | -//! makes `Result` especially useful with functions that may |
91 | | -//! encounter errors but don't otherwise return a useful value. |
| 86 | +//! A common problem with using return values to indicate errors is |
| 87 | +//! that it is easy to ignore the return value, thus failing to handle |
| 88 | +//! the error. Result is annotated with the #[must_use] attribute, |
| 89 | +//! which will cause the compiler to issue a warning when a Result |
| 90 | +//! value is ignored. This makes `Result` especially useful with |
| 91 | +//! functions that may encounter errors but don't otherwise return a |
| 92 | +//! useful value. |
92 | 93 | //! |
93 | 94 | //! Consider the `write_line` method defined for I/O types |
94 | 95 | //! by the [`Writer`](../io/trait.Writer.html) trait: |
|
126 | 127 | //! success with `expect`. This will fail if the write fails, proving |
127 | 128 | //! a marginally useful message indicating why: |
128 | 129 | //! |
129 | | -//! ~~~ |
130 | | -//! # // not running this test because it creates a file |
131 | | -//! # fn do_not_run_test() { |
| 130 | +//! ~~~no_run |
132 | 131 | //! use std::io::{File, Open, Write}; |
133 | 132 | //! |
134 | 133 | //! let mut file = File::open_mode(&Path::new("valuable_data.txt"), Open, Write); |
135 | 134 | //! file.write_line("important message").ok().expect("failed to write message"); |
136 | 135 | //! drop(file); |
137 | | -//! # } |
138 | 136 | //! ~~~ |
139 | 137 | //! |
140 | 138 | //! You might also simply assert success: |
141 | 139 | //! |
142 | | -//! ~~~ |
143 | | -//! # // not running this test because it creates a file |
144 | | -//! # fn do_not_run_test() { |
| 140 | +//! ~~~no_run |
145 | 141 | //! # use std::io::{File, Open, Write}; |
146 | 142 | //! |
147 | 143 | //! # let mut file = File::open_mode(&Path::new("valuable_data.txt"), Open, Write); |
148 | 144 | //! assert!(file.write_line("important message").is_ok()); |
149 | 145 | //! # drop(file); |
150 | | -//! # } |
151 | 146 | //! ~~~ |
152 | 147 | //! |
153 | 148 | //! Or propagate the error up the call stack with `try!`: |
|
215 | 210 | //! `Err` is returned early from the enclosing function. Its simple definition |
216 | 211 | //! makes it clear: |
217 | 212 | //! |
218 | | -//! ~~~ignore |
| 213 | +//! ~~~ |
| 214 | +//! # #![feature(macro_rules)] |
219 | 215 | //! macro_rules! try( |
220 | 216 | //! ($e:expr) => (match $e { Ok(e) => e, Err(e) => return Err(e) }) |
221 | 217 | //! ) |
| 218 | +//! # fn main() { } |
222 | 219 | //! ~~~ |
223 | 220 | //! |
224 | 221 | //! `try!` is imported by the prelude, and is available everywhere. |
|
0 commit comments