Skip to content

Commit 5ab3058

Browse files
committed
change back to anchors; divs break md
1 parent f7d8b41 commit 5ab3058

File tree

1 file changed

+18
-18
lines changed

1 file changed

+18
-18
lines changed

src/doc/trpl/error-handling.md

+18-18
Original file line numberDiff line numberDiff line change
@@ -87,7 +87,8 @@ thread '<main>' panicked at 'Invalid number: 11', src/bin/panic-simple.rs:5
8787
Here's another example that is slightly less contrived. A program that accepts
8888
an integer as an argument, doubles it and prints it.
8989

90-
<div id="code-unwrap-double">
90+
<a name="code-unwrap-double"></a>
91+
9192
```rust,should_panic
9293
use std::env;
9394
@@ -98,7 +99,6 @@ fn main() {
9899
println!("{}", 2 * n);
99100
}
100101
```
101-
</div>
102102

103103
If you give this program zero arguments (error 1) or if the first argument
104104
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
139139
programmer to handle that absence. Let's take a look at an example that tries
140140
to find a character in a string:
141141

142-
<div id="code-option-ex-string-find">
142+
<a name="code-option-ex-string-find"></a>
143+
143144
```rust
144145
// Searches `haystack` for the Unicode character `needle`. If one is found, the
145146
// byte offset of the character is returned. Otherwise, `None` is returned.
@@ -152,7 +153,6 @@ fn find(haystack: &str, needle: char) -> Option<usize> {
152153
None
153154
}
154155
```
155-
</div>
156156

157157
Notice that when this function finds a matching character, it doen't just
158158
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)?
186186
There was no case analysis there! Instead, the case analysis was put inside the
187187
`unwrap` method for you. You could define it yourself if you want:
188188

189-
<div id="code-option-def-unwrap">
189+
<a name="code-option-def-unwrap"></a>
190+
190191
```rust
191192
enum Option<T> {
192193
None,
@@ -203,7 +204,6 @@ impl<T> Option<T> {
203204
}
204205
}
205206
```
206-
</div>
207207

208208
The `unwrap` method *abstracts away the case analysis*. This is precisely the thing
209209
that makes `unwrap` ergonomic to use. Unfortunately, that `panic!` means that
@@ -253,7 +253,8 @@ option is `None`, in which case, just return `None`.
253253
Rust has parametric polymorphism, so it is very easy to define a combinator
254254
that abstracts this pattern:
255255

256-
<div id="code-option-map">
256+
<a name="code-option-map"></a>
257+
257258
```rust
258259
fn map<F, T, A>(option: Option<T>, f: F) -> Option<A> where F: FnOnce(T) -> A {
259260
match option {
@@ -262,7 +263,6 @@ fn map<F, T, A>(option: Option<T>, f: F) -> Option<A> where F: FnOnce(T) -> A {
262263
}
263264
}
264265
```
265-
</div>
266266

267267
Indeed, `map` is [defined as a method][2] on `Option<T>` in the standard library.
268268

@@ -394,14 +394,14 @@ remove choices because they will panic if `Option<T>` is `None`.
394394
The `Result` type is also
395395
[defined in the standard library][6]:
396396

397-
<div id="code-result-def-1">
397+
<a name="code-result-def-1"></a>
398+
398399
```rust
399400
enum Result<T, E> {
400401
Ok(T),
401402
Err(E),
402403
}
403404
```
404-
</div>
405405

406406
The `Result` type is a richer version of `Option`. Instead of expressing the
407407
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
672672
(from `env::args()`) means the user didn't invoke the program correctly. We
673673
could just use a `String` to describe the error. Let's try:
674674

675-
<div id="code-error-double-string">
675+
<a name="code-error-double-string"></a>
676+
676677
```rust
677678
use std::env;
678679

@@ -689,7 +690,6 @@ fn main() {
689690
}
690691
}
691692
```
692-
</div>
693693

694694
There are a couple new things in this example. The first is the use of the
695695
[`Option::ok_or`](../std/option/enum.Option.html#method.ok_or)
@@ -906,7 +906,8 @@ seen above.
906906

907907
Here is a simplified definition of a `try!` macro:
908908

909-
<div id="code-try-def-simple">
909+
<a nama name="code-try-def-simple"></a>
910+
910911
```rust
911912
macro_rules! try {
912913
($e:expr) => (match $e {
@@ -915,7 +916,6 @@ macro_rules! try {
915916
});
916917
}
917918
```
918-
</div>
919919

920920
(The [real definition](../std/macro.try!.html) is a bit more
921921
sophisticated. We will address that later.)
@@ -1168,13 +1168,13 @@ The `std::convert::From` trait is
11681168
[defined in the standard
11691169
library](../std/convert/trait.From.html):
11701170

1171-
<div id="code-from-def">
1171+
<a name="code-from-def"></a>
1172+
11721173
```rust
11731174
trait From<T> {
11741175
fn from(T) -> Self;
11751176
}
11761177
```
1177-
</div>
11781178

11791179
Deliciously simple, yes? `From` is very useful because it gives us a generic
11801180
way to talk about conversion *from* a particular type `T` to some other type
@@ -1250,7 +1250,8 @@ macro_rules! try {
12501250
This is not its real definition. Its real definition is
12511251
[in the standard library](../std/macro.try!.html):
12521252

1253-
<div id="code-try-def">
1253+
<a name="code-try-def"></a>
1254+
12541255
```rust
12551256
macro_rules! try {
12561257
($e:expr) => (match $e {
@@ -1259,7 +1260,6 @@ macro_rules! try {
12591260
});
12601261
}
12611262
```
1262-
</div>
12631263

12641264
There's one tiny but powerful change: the error value is passed through
12651265
`From::from`. This makes the `try!` macro a lot more powerful because it gives

0 commit comments

Comments
 (0)