Skip to content

Commit e69bd81

Browse files
committed
doc: Address review feedback
1 parent 46cb598 commit e69bd81

File tree

1 file changed

+14
-17
lines changed

1 file changed

+14
-17
lines changed

src/libstd/result.rs

+14-17
Original file line numberDiff line numberDiff line change
@@ -35,7 +35,7 @@
3535
//!
3636
//! fn parse_version(header: &[u8]) -> Result<Version, &'static str> {
3737
//! if header.len() < 1 {
38-
//! return Err("invalid header length");;
38+
//! return Err("invalid header length");
3939
//! }
4040
//! match header[0] {
4141
//! 1 => Ok(Version1),
@@ -77,18 +77,19 @@
7777
//! // Use `or_else` to handle the error.
7878
//! let bad_result: Result<int, int> = bad_result.or_else(|i| Ok(11));
7979
//!
80-
//! // Convert to an `Option` to call e.g. `unwrap`.
80+
//! // Consume the result and return the contents with `unwrap`.
8181
//! let final_awesome_result = good_result.ok().unwrap();
8282
//! ~~~
8383
//!
8484
//! # Results must be used
8585
//!
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.
9293
//!
9394
//! Consider the `write_line` method defined for I/O types
9495
//! by the [`Writer`](../io/trait.Writer.html) trait:
@@ -126,28 +127,22 @@
126127
//! success with `expect`. This will fail if the write fails, proving
127128
//! a marginally useful message indicating why:
128129
//!
129-
//! ~~~
130-
//! # // not running this test because it creates a file
131-
//! # fn do_not_run_test() {
130+
//! ~~~no_run
132131
//! use std::io::{File, Open, Write};
133132
//!
134133
//! let mut file = File::open_mode(&Path::new("valuable_data.txt"), Open, Write);
135134
//! file.write_line("important message").ok().expect("failed to write message");
136135
//! drop(file);
137-
//! # }
138136
//! ~~~
139137
//!
140138
//! You might also simply assert success:
141139
//!
142-
//! ~~~
143-
//! # // not running this test because it creates a file
144-
//! # fn do_not_run_test() {
140+
//! ~~~no_run
145141
//! # use std::io::{File, Open, Write};
146142
//!
147143
//! # let mut file = File::open_mode(&Path::new("valuable_data.txt"), Open, Write);
148144
//! assert!(file.write_line("important message").is_ok());
149145
//! # drop(file);
150-
//! # }
151146
//! ~~~
152147
//!
153148
//! Or propagate the error up the call stack with `try!`:
@@ -215,10 +210,12 @@
215210
//! `Err` is returned early from the enclosing function. Its simple definition
216211
//! makes it clear:
217212
//!
218-
//! ~~~ignore
213+
//! ~~~
214+
//! # #![feature(macro_rules)]
219215
//! macro_rules! try(
220216
//! ($e:expr) => (match $e { Ok(e) => e, Err(e) => return Err(e) })
221217
//! )
218+
//! # fn main() { }
222219
//! ~~~
223220
//!
224221
//! `try!` is imported by the prelude, and is available everywhere.

0 commit comments

Comments
 (0)