@@ -87,7 +87,8 @@ thread '<main>' panicked at 'Invalid number: 11', src/bin/panic-simple.rs:5
87
87
Here's another example that is slightly less contrived. A program that accepts
88
88
an integer as an argument, doubles it and prints it.
89
89
90
- <div id =" code-unwrap-double " >
90
+ <a name =" code-unwrap-double " ></a >
91
+
91
92
``` rust,should_panic
92
93
use std::env;
93
94
@@ -98,7 +99,6 @@ fn main() {
98
99
println!("{}", 2 * n);
99
100
}
100
101
```
101
- </div >
102
102
103
103
If you give this program zero arguments (error 1) or if the first argument
104
104
isn't an integer (error 2), the program will panic just like in the first
@@ -139,7 +139,8 @@ system is an important concept because it will cause the compiler to force the
139
139
programmer to handle that absence. Let's take a look at an example that tries
140
140
to find a character in a string:
141
141
142
- <div id =" code-option-ex-string-find " >
142
+ <a name =" code-option-ex-string-find " ></a >
143
+
143
144
``` rust
144
145
// Searches `haystack` for the Unicode character `needle`. If one is found, the
145
146
// byte offset of the character is returned. Otherwise, `None` is returned.
@@ -152,7 +153,6 @@ fn find(haystack: &str, needle: char) -> Option<usize> {
152
153
None
153
154
}
154
155
```
155
- </div >
156
156
157
157
Notice that when this function finds a matching character, it doen't just
158
158
return the ` offset ` . Instead, it returns ` Some(offset) ` . ` Some ` is a variant or
@@ -186,7 +186,8 @@ But wait, what about `unwrap` used in [`unwrap-double`](#code-unwrap-double)?
186
186
There was no case analysis there! Instead, the case analysis was put inside the
187
187
` unwrap ` method for you. You could define it yourself if you want:
188
188
189
- <div id =" code-option-def-unwrap " >
189
+ <a name =" code-option-def-unwrap " ></a >
190
+
190
191
``` rust
191
192
enum Option <T > {
192
193
None ,
@@ -203,7 +204,6 @@ impl<T> Option<T> {
203
204
}
204
205
}
205
206
```
206
- </div >
207
207
208
208
The ` unwrap ` method * abstracts away the case analysis* . This is precisely the thing
209
209
that makes ` unwrap ` ergonomic to use. Unfortunately, that ` panic! ` means that
@@ -253,7 +253,8 @@ option is `None`, in which case, just return `None`.
253
253
Rust has parametric polymorphism, so it is very easy to define a combinator
254
254
that abstracts this pattern:
255
255
256
- <div id =" code-option-map " >
256
+ <a name =" code-option-map " ></a >
257
+
257
258
``` rust
258
259
fn map <F , T , A >(option : Option <T >, f : F ) -> Option <A > where F : FnOnce (T ) -> A {
259
260
match option {
@@ -262,7 +263,6 @@ fn map<F, T, A>(option: Option<T>, f: F) -> Option<A> where F: FnOnce(T) -> A {
262
263
}
263
264
}
264
265
```
265
- </div >
266
266
267
267
Indeed, ` map ` is [ defined as a method] [ 2 ] on ` Option<T> ` in the standard library.
268
268
@@ -394,14 +394,14 @@ remove choices because they will panic if `Option<T>` is `None`.
394
394
The ` Result ` type is also
395
395
[ defined in the standard library] [ 6 ] :
396
396
397
- <div id =" code-result-def-1 " >
397
+ <a name =" code-result-def-1 " ></a >
398
+
398
399
``` rust
399
400
enum Result <T , E > {
400
401
Ok (T ),
401
402
Err (E ),
402
403
}
403
404
```
404
- </div >
405
405
406
406
The ` Result ` type is a richer version of ` Option ` . Instead of expressing the
407
407
possibility of * absence* like ` Option ` does, ` Result ` expresses the possibility
@@ -672,7 +672,8 @@ with both an `Option` and a `Result`, the solution is *usually* to convert the
672
672
(from ` env::args() ` ) means the user didn't invoke the program correctly. We
673
673
could just use a ` String ` to describe the error. Let's try:
674
674
675
- <div id =" code-error-double-string " >
675
+ <a name =" code-error-double-string " ></a >
676
+
676
677
``` rust
677
678
use std :: env;
678
679
@@ -689,7 +690,6 @@ fn main() {
689
690
}
690
691
}
691
692
```
692
- </div >
693
693
694
694
There are a couple new things in this example. The first is the use of the
695
695
[ ` Option::ok_or ` ] ( ../std/option/enum.Option.html#method.ok_or )
@@ -906,7 +906,8 @@ seen above.
906
906
907
907
Here is a simplified definition of a ` try! ` macro:
908
908
909
- <div id =" code-try-def-simple " >
909
+ <a nama name =" code-try-def-simple " ></a >
910
+
910
911
``` rust
911
912
macro_rules! try {
912
913
($ e : expr ) => (match $ e {
@@ -915,7 +916,6 @@ macro_rules! try {
915
916
});
916
917
}
917
918
```
918
- </div >
919
919
920
920
(The [ real definition] ( ../std/macro.try!.html ) is a bit more
921
921
sophisticated. We will address that later.)
@@ -1168,13 +1168,13 @@ The `std::convert::From` trait is
1168
1168
[ defined in the standard
1169
1169
library] ( ../std/convert/trait.From.html ) :
1170
1170
1171
- <div id =" code-from-def " >
1171
+ <a name =" code-from-def " ></a >
1172
+
1172
1173
``` rust
1173
1174
trait From <T > {
1174
1175
fn from (T ) -> Self ;
1175
1176
}
1176
1177
```
1177
- </div >
1178
1178
1179
1179
Deliciously simple, yes? ` From ` is very useful because it gives us a generic
1180
1180
way to talk about conversion * from* a particular type ` T ` to some other type
@@ -1250,7 +1250,8 @@ macro_rules! try {
1250
1250
This is not its real definition. Its real definition is
1251
1251
[ in the standard library] ( ../std/macro.try!.html ) :
1252
1252
1253
- <div id =" code-try-def " >
1253
+ <a name =" code-try-def " ></a >
1254
+
1254
1255
``` rust
1255
1256
macro_rules! try {
1256
1257
($ e : expr ) => (match $ e {
@@ -1259,7 +1260,6 @@ macro_rules! try {
1259
1260
});
1260
1261
}
1261
1262
```
1262
- </div >
1263
1263
1264
1264
There's one tiny but powerful change: the error value is passed through
1265
1265
` From::from ` . This makes the ` try! ` macro a lot more powerful because it gives
0 commit comments