|
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