---

yaml
---
r: 234724
b: refs/heads/tmp
c: 3a5e9a3
h: refs/heads/master
v: v3

Author: davidszotten

[refs]

@@ -25,7 +25,7 @@ refs/tags/0.11.0: e1247cb1d0d681be034adb4b558b5a0c0d5720f9
 refs/tags/0.12.0: f0c419429ef30723ceaf6b42f9b5a2aeb5d2e2d1
 refs/heads/beta: d2e13e822a73e0ea46ae9e21afdd3155fc997f6d
 refs/tags/1.0.0-alpha: e42bd6d93a1d3433c486200587f8f9e12590a4d7
-refs/heads/tmp: 30c91cd7f7527cee89e4997827fbe61ea39f2729
+refs/heads/tmp: 3a5e9a3f9934a850753110769c49521a659cd03a
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: ab792abf1fcc28afbd315426213f6428da25c085
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828

branches/tmp/src/doc/trpl/error-handling.md

@@ -186,6 +186,7 @@ But wait, what about `unwrap` used in [`unwrap-double`](#code-unwrap-double)?
 There was no case analysis there! Instead, the case analysis was put inside the
 `unwrap` method for you. You could define it yourself if you want:
 
+<div id="code-option-def-unwrap">
 ```rust
 enum Option<T> {
     None,
@@ -202,6 +203,7 @@ impl<T> Option<T> {
     }
 }
 ```
+</div>
 
 The `unwrap` method *abstracts away the case analysis*. This is precisely the thing
 that makes `unwrap` ergonomic to use. Unfortunately, that `panic!` means that
@@ -251,6 +253,7 @@ option is `None`, in which case, just return `None`.
 Rust has parametric polymorphism, so it is very easy to define a combinator
 that abstracts this pattern:
 
+<div id="code-option-map">
 ```rust
 fn map<F, T, A>(option: Option<T>, f: F) -> Option<A> where F: FnOnce(T) -> A {
     match option {
@@ -259,6 +262,7 @@ fn map<F, T, A>(option: Option<T>, f: F) -> Option<A> where F: FnOnce(T) -> A {
     }
 }
 ```
+</div>
 
 Indeed, `map` is [defined as a method][2] on `Option<T>` in the standard library.
 
@@ -390,12 +394,14 @@ remove choices because they will panic if `Option<T>` is `None`.
 The `Result` type is also
 [defined in the standard library][6]:
 
+<div id="code-result-def-1">
 ```rust
 enum Result<T, E> {
     Ok(T),
     Err(E),
 }
 ```
+</div>
 
 The `Result` type is a richer version of `Option`. Instead of expressing the
 possibility of *absence* like `Option` does, `Result` expresses the possibility
@@ -666,6 +672,7 @@ with both an `Option` and a `Result`, the solution is *usually* to convert the
 (from `env::args()`) means the user didn't invoke the program correctly. We
 could just use a `String` to describe the error. Let's try:
 
+<div id="code-error-double-string">
 ```rust
 use std::env;
 
@@ -682,6 +689,7 @@ fn main() {
     }
 }
 ```
+</div>
 
 There are a couple new things in this example. The first is the use of the
 [`Option::ok_or`](../std/option/enum.Option.html#method.ok_or)
@@ -898,6 +906,7 @@ seen above.
 
 Here is a simplified definition of a `try!` macro:
 
+<div id="code-try-def-simple">
 ```rust
 macro_rules! try {
     ($e:expr) => (match $e {
@@ -906,6 +915,7 @@ macro_rules! try {
     });
 }
 ```
+</div>
 
 (The [real definition](../std/macro.try!.html) is a bit more
 sophisticated. We will address that later.)
@@ -1158,11 +1168,13 @@ The `std::convert::From` trait is
 [defined in the standard
 library](../std/convert/trait.From.html):
 
+<div id="code-from-def">
 ```rust
 trait From<T> {
     fn from(T) -> Self;
 }
 ```
+</div>
 
 Deliciously simple, yes? `From` is very useful because it gives us a generic
 way to talk about conversion *from* a particular type `T` to some other type
@@ -1238,6 +1250,7 @@ macro_rules! try {
 This is not it's real definition. It's real definition is
 [in the standard library](../std/macro.try!.html):
 
+<div id="code-try-def">
 ```rust
 macro_rules! try {
     ($e:expr) => (match $e {
@@ -1246,6 +1259,7 @@ macro_rules! try {
     });
 }
 ```
+</div>
 
 There's one tiny but powerful change: the error value is passed through
 `From::from`. This makes the `try!` macro a lot more powerful because it gives