From c17e326057790be2bfe5b526143cf8ee5b8792a6 Mon Sep 17 00:00:00 2001
From: Tatsuya Kawano <tatsuya@hibaridb.org>
Date: Thu, 18 Feb 2016 13:00:12 +0800
Subject: [PATCH 1/6] Translate error-handling (part 3)

---
 1.6/ja/book/error-handling.md | 510 +++++++++++++++++++++-------------
 TranslationTable.md           |   1 +
 2 files changed, 322 insertions(+), 189 deletions(-)

diff --git a/1.6/ja/book/error-handling.md b/1.6/ja/book/error-handling.md
index cd112d8b..f2e58ebc 100644
--- a/1.6/ja/book/error-handling.md
+++ b/1.6/ja/book/error-handling.md
@@ -78,12 +78,12 @@ Rustでは戻り値を使います。
     * [早期のリターン](#早期のリターン)
     * [`try!` マクロ](#try-マクロ)
     * [独自のエラー型を定義する](#独自のエラー型を定義する)
-* [標準ライブラリのトレイトによるエラー処理](#standard-library-traits-used-for-error-handling)
-    * [`Error` トレイト](#the-error-trait)
-    * [`From` トレイト](#the-from-trait)
-    * [本当の `try!` マクロ](#the-real-try-macro)
-    * [独自のエラー型を合成する](#composing-custom-error-types)
-    * [ライブラリ作者たちへのアドバイス](#advice-for-library-writers)
+* [標準ライブラリのトレイトによるエラー処理](#標準ライブラリのトレイトによるエラー処理)
+    * [`Error` トレイト](#error-トレイト)
+    * [`From` トレイト](#from-トレイト)
+    * [本当の `try!` マクロ](#本当の-try-マクロ)
+    * [独自のエラー型を合成する](#独自のエラー型を合成する)
+    * [ライブラリ作者たちへのアドバイス](#ライブラリ作者たちへのアドバイス)
 * [ケーススタディ：人口データを読み込むプログラム](#case-study-a-program-to-read-population-data)
     * [最初のセットアップ](#initial-setup)
     * [引数のパース](#argument-parsing)
@@ -1475,61 +1475,87 @@ fn main() {
 特にアプリケーションを書いている時などはそうです。
 もしライブラリを書いているのなら、呼び出し元の選択肢を理由もなく奪わないために、独自のエラー型を定義することを強く推奨します。
 
-# Standard library traits used for error handling
+<!-- # Standard library traits used for error handling -->
+# 標準ライブラリのトレイトによるエラー処理
 
-The standard library defines two integral traits for error handling:
-[`std::error::Error`](../std/error/trait.Error.html) and
-[`std::convert::From`](../std/convert/trait.From.html). While `Error`
-is designed specifically for generically describing errors, the `From`
-trait serves a more general role for converting values between two
-distinct types.
+<!-- The standard library defines two integral traits for error handling: -->
+<!-- [`std::error::Error`](../std/error/trait.Error.html) and -->
+<!-- [`std::convert::From`](../std/convert/trait.From.html). While `Error` -->
+<!-- is designed specifically for generically describing errors, the `From` -->
+<!-- trait serves a more general role for converting values between two -->
+<!-- distinct types. -->
+標準ライブラリでは、エラーハンドリングに欠かせないトレイトが、2つ定義されています：
+[`std::error::Error`](../std/error/trait.Error.html) と [`std::convert::From`](../std/convert/trait.From.html) です。
+`Error` はエラーを総称的に説明することを目的に設計されているのに対し、 `From` トレイトはもっと汎用的な、2つの異なる型の間で値を変換する役割を担います。
 
-## The `Error` trait
+<!-- ## The `Error` trait -->
+## `Error` トレイト
 
-The `Error` trait is [defined in the standard
-library](../std/error/trait.Error.html):
+<!-- The `Error` trait is [defined in the standard -->
+<!-- library](../std/error/trait.Error.html): -->
+`Error` トレイトは [標準ライブラリで定義されています](../std/error/trait.Error.html) ：
 
 ```rust
 use std::fmt::{Debug, Display};
 
 trait Error: Debug + Display {
-  /// A short description of the error.
+#  /// A short description of the error.
+  /// エラーの簡単な説明
   fn description(&self) -> &str;
 
-  /// The lower level cause of this error, if any.
+#   /// The lower level cause of this error, if any.
+  /// このエラーの一段下のレベルの原因（もしあれば）
   fn cause(&self) -> Option<&Error> { None }
 }
 ```
 
-This trait is super generic because it is meant to be implemented for *all*
-types that represent errors. This will prove useful for writing composable code
-as we'll see later. Otherwise, the trait allows you to do at least the
-following things:
-
-* Obtain a `Debug` representation of the error.
-* Obtain a user-facing `Display` representation of the error.
-* Obtain a short description of the error (via the `description` method).
-* Inspect the causal chain of an error, if one exists (via the `cause` method).
-
-The first two are a result of `Error` requiring impls for both `Debug` and
-`Display`. The latter two are from the two methods defined on `Error`. The
-power of `Error` comes from the fact that all error types impl `Error`, which
-means errors can be existentially quantified as a
-[trait object](../book/trait-objects.html).
-This manifests as either `Box<Error>` or `&Error`. Indeed, the `cause` method
-returns an `&Error`, which is itself a trait object. We'll revisit the
-`Error` trait's utility as a trait object later.
-
-For now, it suffices to show an example implementing the `Error` trait. Let's
-use the error type we defined in the
-[previous section](#defining-your-own-error-type):
+<!-- This trait is super generic because it is meant to be implemented for *all* -->
+<!-- types that represent errors. This will prove useful for writing composable code -->
+<!-- as we'll see later. Otherwise, the trait allows you to do at least the -->
+<!-- following things: -->
+このトレイトはエラーを表す *全て* の型で実装されることを目的としており、ごく一般的なデフォルト実装を持ちます。
+この後すぐ見るように、このことが合成可能なコードを書くのに役立っています。
+一方で、このトレイトは最低でも以下のようなカスタマイズを可能にします：
+
+<!-- * Obtain a `Debug` representation of the error. -->
+<!-- * Obtain a user-facing `Display` representation of the error. -->
+<!-- * Obtain a short description of the error (via the `description` method). -->
+<!-- * Inspect the causal chain of an error, if one exists (via the `cause` method). -->
+* エラーの `Debug` 表現を取得する
+* エラーのユーザー向けの `Display` 表現を取得する
+* エラーの簡単な説明を取得する（`cause` メソッド経由）
+* エラーの因果関係のチェーンが提供されているなら、それを調べる（`cause` メソッド経由）
+
+<!-- The first two are a result of `Error` requiring impls for both `Debug` and -->
+<!-- `Display`. The latter two are from the two methods defined on `Error`. The -->
+<!-- power of `Error` comes from the fact that all error types impl `Error`, which -->
+<!-- means errors can be existentially quantified as a -->
+<!-- [trait object](../book/trait-objects.html). -->
+<!-- This manifests as either `Box<Error>` or `&Error`. Indeed, the `cause` method -->
+<!-- returns an `&Error`, which is itself a trait object. We'll revisit the -->
+<!-- `Error` trait's utility as a trait object later. -->
+最初の2つは `Error` が `Debug` と `Display` の実装を必要としていることに由来します。
+残りの2つは `Error` が定義している2つのメソッドに由来します。
+`Error` の強力さは、実際に全てのエラー型が `Error` を実装していることから来ています。
+このことは、全てのエラーを1つの [トレイトオブジェクト](../book/trait-objects.html) として存在量化(existentially quantify) できることを意味します。
+これは `Box<Error>` または `&Error` と書くことで表明できます。
+まさに `cause` メソッドは `&Error` を返し、それ自身がトレイトオブジェクトです。
+`Error` トレイトのトレイトオブジェクトとしての用例については、後ほど再び取り上げます。
+
+<!-- For now, it suffices to show an example implementing the `Error` trait. Let's -->
+<!-- use the error type we defined in the -->
+<!-- [previous section](#defining-your-own-error-type): -->
+`Error` トレイトの実装例を見せるには十分でしょう。
+[前の節](#独自のエラー型を定義する) で定義したエラー型を使ってみましょう：
 
 ```rust
 use std::io;
 use std::num;
 
-// We derive `Debug` because all types should probably derive `Debug`.
-// This gives us a reasonable human readable description of `CliError` values.
+# // We derive `Debug` because all types should probably derive `Debug`.
+# // This gives us a reasonable human readable description of `CliError` values.
+// 全ての型は `Debug` を導出するべきでしょうから、ここでも `Debug` を導出します。
+// これにより `CliError` 値について、人間が十分理解できる説明を得られます。
 #[derive(Debug)]
 enum CliError {
     Io(io::Error),
@@ -1537,13 +1563,17 @@ enum CliError {
 }
 ```
 
-This particular error type represents the possibility of two types of errors
-occurring: an error dealing with I/O or an error converting a string to a
-number. The error could represent as many error types as you want by adding new
-variants to the `enum` definition.
+<!-- This particular error type represents the possibility of two types of errors -->
+<!-- occurring: an error dealing with I/O or an error converting a string to a -->
+<!-- number. The error could represent as many error types as you want by adding new -->
+<!-- variants to the `enum` definition. -->
+このエラー型は2種類のエラー、つまり、IOを扱っている時のエラー、または、文字列を通知に変換するときのエラーが起こる可能性を示しています。
+`enum` 定義にバリエーションを加えることで、エラーの種類をいくらでも表現できます。
 
-Implementing `Error` is pretty straight-forward. It's mostly going to be a lot
-explicit case analysis.
+<!-- Implementing `Error` is pretty straight-forward. It's mostly going to be a lot -->
+<!-- explicit case analysis. -->
+`Error` を実装するのは実に単純な作業です。
+ほとんどの場合は明示的な場合分けの繰り返しになります。
 
 ```rust,ignore
 use std::error;
@@ -1552,8 +1582,10 @@ use std::fmt;
 impl fmt::Display for CliError {
     fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
         match *self {
-            // Both underlying errors already impl `Display`, so we defer to
-            // their implementations.
+#           // Both underlying errors already impl `Display`, so we defer to
+#           // their implementations.
+            // 下層のエラーは両方ともすでに `Display` を実装しているので、
+            // それらの実装に従います。
             CliError::Io(ref err) => write!(f, "IO error: {}", err),
             CliError::Parse(ref err) => write!(f, "Parse error: {}", err),
         }
@@ -1562,8 +1594,10 @@ impl fmt::Display for CliError {
 
 impl error::Error for CliError {
     fn description(&self) -> &str {
-        // Both underlying errors already impl `Error`, so we defer to their
-        // implementations.
+#       // Both underlying errors already impl `Error`, so we defer to their
+#       // implementations.
+        // 下層のエラーは両方ともすでに `Error` を実装しているので、
+        // それらの実装に従います。
         match *self {
             CliError::Io(ref err) => err.description(),
             CliError::Parse(ref err) => err.description(),
@@ -1572,10 +1606,14 @@ impl error::Error for CliError {
 
     fn cause(&self) -> Option<&error::Error> {
         match *self {
-            // N.B. Both of these implicitly cast `err` from their concrete
-            // types (either `&io::Error` or `&num::ParseIntError`)
-            // to a trait object `&Error`. This works because both error types
-            // implement `Error`.
+#           // N.B. Both of these implicitly cast `err` from their concrete
+#           // types (either `&io::Error` or `&num::ParseIntError`)
+#           // to a trait object `&Error`. This works because both error types
+#           // implement `Error`.
+            // 注意：これらは両方とも `err` を、その具象型（`&io::Error` か
+            // `&num::ParseIntError` のいずれか）から、トレイトオブジェクト
+            // `&Error` へ暗黙的にキャストします。どちらのエラー型も `Error` を
+            // 実装しているので、問題なく動きます。
             CliError::Io(ref err) => Some(err),
             CliError::Parse(ref err) => Some(err),
         }
@@ -1583,15 +1621,19 @@ impl error::Error for CliError {
 }
 ```
 
-We note that this is a very typical implementation of `Error`: match on your
-different error types and satisfy the contracts defined for `description` and
-`cause`.
+<!-- We note that this is a very typical implementation of `Error`: match on your -->
+<!-- different error types and satisfy the contracts defined for `description` and -->
+<!-- `cause`. -->
+これは極めて典型的な `Error` の実装だということに留意してください。
+このように異なるエラー型にマッチさせて、`description` と `cause` のコントラクトを満たします。
 
-## The `From` trait
+<!-- ## The `From` trait -->
+## `From` トレイト
 
-The `std::convert::From` trait is
-[defined in the standard
-library](../std/convert/trait.From.html):
+<!-- The `std::convert::From` trait is -->
+<!-- [defined in the standard -->
+<!-- library](../std/convert/trait.From.html): -->
+`std::convert::From` は [標準ライブラリで定義されています](../std/convert/trait.From.html) ：
 
 <span id="code-from-def"></span>
 
@@ -1601,14 +1643,19 @@ trait From<T> {
 }
 ```
 
-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
-(in this case, “some other type” is the subject of the impl, or `Self`).
-The crux of `From` is the
-[set of implementations provided by the standard
-library](../std/convert/trait.From.html).
+<!-- 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 -->
+<!-- (in this case, “some other type” is the subject of the impl, or `Self`). -->
+<!-- The crux of `From` is the -->
+<!-- [set of implementations provided by the standard -->
+<!-- library](../std/convert/trait.From.html). -->
+嬉しいくらい簡単でしょ？
+`From` は、ある特定の型 `T` から違う型へ変換するための汎用的な方法を提供するので大変便利です
+（この場合の「違う型」とは実装の対象、つまり `Self` です）。
+`From` で最も重要なのは [標準ライブラリで提供される一連の実装です](../std/convert/trait.From.html)。
 
-Here are a few simple examples demonstrating how `From` works:
+<!-- Here are a few simple examples demonstrating how `From` works: -->
+`From` がどのように動くか、いくつかの例を使って紹介しましょう：
 
 ```rust
 let string: String = From::from("foo");
@@ -1616,20 +1663,28 @@ let bytes: Vec<u8> = From::from("foo");
 let cow: ::std::borrow::Cow<str> = From::from("foo");
 ```
 
-OK, so `From` is useful for converting between strings. But what about errors?
-It turns out, there is one critical impl:
+<!-- OK, so `From` is useful for converting between strings. But what about errors? -->
+<!-- It turns out, there is one critical impl: -->
+たしかに `From` が文字列を変換するのに便利なことはわかりました。
+でもエラーについてはどうでしょうか？
+結論から言うと、これが最も重要な実装です：
 
 ```rust,ignore
 impl<'a, E: Error + 'a> From<E> for Box<Error + 'a>
 ```
 
-This impl says that for *any* type that impls `Error`, we can convert it to a
-trait object `Box<Error>`. This may not seem terribly surprising, but it is
-useful in a generic context.
+<!-- This impl says that for *any* type that impls `Error`, we can convert it to a -->
+<!-- trait object `Box<Error>`. This may not seem terribly surprising, but it is -->
+<!-- useful in a generic context. -->
+この実装では、 `Error` を実装した *全て* の型は、トレイトオブジェクト `Box<Error>` に変換できると言っています。
+これは、あまり驚くほどのものには見えませんが、一般的な状況では有用です。
 
-Remember the two errors we were dealing with previously? Specifically,
-`io::Error` and `num::ParseIntError`. Since both impl `Error`, they work with
-`From`:
+<!-- Remember the two errors we were dealing with previously? Specifically, -->
+<!-- `io::Error` and `num::ParseIntError`. Since both impl `Error`, they work with -->
+<!-- `From`: -->
+さっき扱った2つのエラーを覚えてますか？
+具体的には `io::Error` と `num::ParseIntError` でした。
+どちらも `Error` を実装していますので `From` で動きます。
 
 ```rust
 use std::error::Error;
@@ -1637,31 +1692,45 @@ use std::fs;
 use std::io;
 use std::num;
 
-// We have to jump through some hoops to actually get error values.
+# // We have to jump through some hoops to actually get error values.
+// エラーの値にたどり着くまで、何段階かのステップが必要です。
 let io_err: io::Error = io::Error::last_os_error();
 let parse_err: num::ParseIntError = "not a number".parse::<i32>().unwrap_err();
 
-// OK, here are the conversions.
+# // OK, here are the conversions.
+// では、こちらで変換します。
 let err1: Box<Error> = From::from(io_err);
 let err2: Box<Error> = From::from(parse_err);
 ```
 
-There is a really important pattern to recognize here. Both `err1` and `err2`
-have the *same type*. This is because they are existentially quantified types,
-or trait objects. In particular, their underlying type is *erased* from the
-compiler's knowledge, so it truly sees `err1` and `err2` as exactly the same.
-Additionally, we constructed `err1` and `err2` using precisely the same
-function call: `From::from`. This is because `From::from` is overloaded on both
-its argument and its return type.
+<!-- There is a really important pattern to recognize here. Both `err1` and `err2` -->
+<!-- have the *same type*. This is because they are existentially quantified types, -->
+<!-- or trait objects. In particular, their underlying type is *erased* from the -->
+<!-- compiler's knowledge, so it truly sees `err1` and `err2` as exactly the same. -->
+<!-- Additionally, we constructed `err1` and `err2` using precisely the same -->
+<!-- function call: `From::from`. This is because `From::from` is overloaded on both -->
+<!-- its argument and its return type. -->
+ここに認識すべき、本当に重要なパターンがあります。
+`err1` と `err2` の両方ともが *同じ型* になっているのです。
+なぜなら、それらが存在量型、つまり、トレイトオブジェクトだからです。
+特にそれらの背後の型は、コンパイラーの知識から *消去されます* ので、 `err1` と `err2` が本当に同じに見えるのです。
+さらに私たちは同じ関数呼び出し `From::from` を使って `err1` と `err2` をコンストラクトしました。
+これは `From::from` が引数とリターン型の両方でオーバーロードされているからです。
 
-This pattern is important because it solves a problem we had earlier: it gives
-us a way to reliably convert errors to the same type using the same function.
+<!-- This pattern is important because it solves a problem we had earlier: it gives -->
+<!-- us a way to reliably convert errors to the same type using the same function. -->
+このパターンは重要です。
+なぜなら、私たちが以前抱えていた問題を解決するからです：
+同じ関数を使って、エラーを同一の型に変換する、確かな方法を提供するからです。
 
-Time to revisit an old friend; the `try!` macro.
+<!-- Time to revisit an old friend; the `try!` macro. -->
+いよいよ、私たちの旧友 `try!` マクロを再訪する時が訪れました。
 
-## The real `try!` macro
+<!-- ## The real `try!` macro -->
+## 本当の `try!` マクロ
 
-Previously, we presented this definition of `try!`:
+<!-- Previously, we presented this definition of `try!`: -->
+`try!` の定義は、以前このように提示されました：
 
 ```rust
 macro_rules! try {
@@ -1672,8 +1741,10 @@ macro_rules! try {
 }
 ```
 
-This is not its real definition. Its real definition is
-[in the standard library](../std/macro.try!.html):
+<!-- This is not its real definition. Its real definition is -->
+<!-- [in the standard library](../std/macro.try!.html): -->
+これは本当の定義ではありません。
+本当の定義は [標準ライブラリの中にあります](../std/macro.try!.html)：
 
 <span id="code-try-def"></span>
 
@@ -1686,12 +1757,17 @@ macro_rules! try {
 }
 ```
 
-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
-you automatic type conversion for free.
+<!-- 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 -->
+<!-- you automatic type conversion for free. -->
+ここには、たった一つですが、大きな違いがあります：
+エラーの値は `From::from` を経て渡されるのです。
+これにより `try!` マクロは、はるかに強力になります。
+なぜなら、自動的な型変換をただで手に入れられるのですから。
 
-Armed with our more powerful `try!` macro, let's take a look at code we wrote
-previously to read a file and convert its contents to an integer:
+<!-- Armed with our more powerful `try!` macro, let's take a look at code we wrote -->
+<!-- previously to read a file and convert its contents to an integer: -->
+強力になった `try!` マクロを手に入れたので、以前書いた、ファイルを読み込んで内容を整数値に変換するコードを見直してみましょう：
 
 ```rust
 use std::fs::File;
@@ -1707,10 +1783,13 @@ fn file_double<P: AsRef<Path>>(file_path: P) -> Result<i32, String> {
 }
 ```
 
-Earlier, we promised that we could get rid of the `map_err` calls. Indeed, all
-we have to do is pick a type that `From` works with. As we saw in the previous
-section, `From` has an impl that lets it convert any error type into a
-`Box<Error>`:
+<!-- Earlier, we promised that we could get rid of the `map_err` calls. Indeed, all -->
+<!-- we have to do is pick a type that `From` works with. As we saw in the previous -->
+<!-- section, `From` has an impl that lets it convert any error type into a -->
+<!-- `Box<Error>`: -->
+以前 `map_err` の呼び出しを取り除くことができると約束しました。
+もちろんです。ここでしなければいけないのは `From` と共に動く型を一つ選ぶことです。
+前の節で見たように `From` の実装の一つは、どんなエラー型でも `Box<Error>` に変換できます：
 
 ```rust
 use std::error::Error;
@@ -1727,40 +1806,63 @@ fn file_double<P: AsRef<Path>>(file_path: P) -> Result<i32, Box<Error>> {
 }
 ```
 
-We are getting very close to ideal error handling. Our code has very little
-overhead as a result from error handling because the `try!` macro encapsulates
-three things simultaneously:
-
-1. Case analysis.
-2. Control flow.
-3. Error type conversion.
-
-When all three things are combined, we get code that is unencumbered by
-combinators, calls to `unwrap` or case analysis.
-
-There's one little nit left: the `Box<Error>` type is *opaque*. If we
-return a `Box<Error>` to the caller, the caller can't (easily) inspect
-underlying error type. The situation is certainly better than `String`
-because the caller can call methods like
-[`description`](../std/error/trait.Error.html#tymethod.description)
-and [`cause`](../std/error/trait.Error.html#method.cause), but the
-limitation remains: `Box<Error>` is opaque. (N.B. This isn't entirely
-true because Rust does have runtime reflection, which is useful in
-some scenarios that are [beyond the scope of this
-chapter](https://crates.io/crates/error).)
-
-It's time to revisit our custom `CliError` type and tie everything together.
-
-## Composing custom error types
-
-In the last section, we looked at the real `try!` macro and how it does
-automatic type conversion for us by calling `From::from` on the error value.
-In particular, we converted errors to `Box<Error>`, which works, but the type
-is opaque to callers.
-
-To fix this, we use the same remedy that we're already familiar with: a custom
-error type. Once again, here is the code that reads the contents of a file and
-converts it to an integer:
+<!-- We are getting very close to ideal error handling. Our code has very little -->
+<!-- overhead as a result from error handling because the `try!` macro encapsulates -->
+<!-- three things simultaneously: -->
+理想的なエラーハンドリングまで、あと一歩です。
+私たちのコードには、エラーハンドリングを終えた後も、ごくわずかなオーバーヘッドしかありません。
+これは `try!` マクロが同時に3つのことをカプセル化するからです：
+
+<!-- 1. Case analysis. -->
+<!-- 2. Control flow. -->
+<!-- 3. Eraror type conversion. -->
+1. 場合分け
+2. 制御フロー
+3. エラー型の変換
+
+<!-- When all three things are combined, we get code that is unencumbered by -->
+<!-- combinators, calls to `unwrap` or case analysis. -->
+これら3つが一つになった時、コンビネータ、 `unwrap` の呼び出し、場合分けなどの邪魔者を排除したコードが得られるのです。
+
+<!-- There's one little nit left: the `Box<Error>` type is *opaque*. If we -->
+<!-- return a `Box<Error>` to the caller, the caller can't (easily) inspect -->
+<!-- underlying error type. The situation is certainly better than `String` -->
+<!-- because the caller can call methods like -->
+<!-- [`description`](../std/error/trait.Error.html#tymethod.description) -->
+<!-- and [`cause`](../std/error/trait.Error.html#method.cause), but the -->
+<!-- limitation remains: `Box<Error>` is opaque. (N.B. This isn't entirely -->
+<!-- true because Rust does have runtime reflection, which is useful in -->
+<!-- some scenarios that are [beyond the scope of this -->
+<!-- chapter](https://crates.io/crates/error).) -->
+あとひとつ、些細なことが残っています：
+`Box<Error>` 型は *オペーク* なのです。
+もし `Box<Error>` を呼び出し元に返すと、呼び出し元では背後のエラー型が何であるかを、（簡単には）調べられません。
+この状況は `String` を返すよりは明らかに改善されてます。
+なぜなら、呼び出し元では [`description`](../std/error/trait.Error.html#tymethod.description) や [`cause`](../std/error/trait.Error.html#method.cause) といったメソッドを呼ぶこともできるからです。
+しかし `Box<Error>` が不透明であるという制限は残ります。
+（注意：これは完全な真実ではありません。
+なぜならRustでは実行時のリフレクションができるからです。
+この方法が有効なシナリオもありますが、[この章で扱う範囲を超えています](https://crates.io/crates/error) ）
+
+<!-- It's time to revisit our custom `CliError` type and tie everything together. -->
+では、私たちのカスタムエラー型 `CliErro` に戻って、全てを一つにまとめ上げましょう。
+
+<!-- ## Composing custom error types -->
+## 独自のエラー型を合成する
+
+<!-- In the last section, we looked at the real `try!` macro and how it does -->
+<!-- automatic type conversion for us by calling `From::from` on the error value. -->
+<!-- In particular, we converted errors to `Box<Error>`, which works, but the type -->
+<!-- is opaque to callers. -->
+最後の説では `try!` マクロの本当の定義を確認し、それが `From::from` をエラーの値に対して呼ぶことで、自動的な型変換をする様子を見ました。
+特にそこでは、エラーを `Box<Error>` に変換しました。
+これはたしかに動きますが、呼び出し元にとって型がオペークになってしまいました。
+
+<!-- To fix this, we use the same remedy that we're already familiar with: a custom -->
+<!-- error type. Once again, here is the code that reads the contents of a file and -->
+<!-- converts it to an integer: -->
+これを直すために、すでによく知っている改善方法である独自のエラー型を使いましょう。
+もう一度、ファイルの内容を読み込んで整数値に変換するコードです：
 
 ```rust
 use std::fs::File;
@@ -1768,8 +1870,10 @@ use std::io::{self, Read};
 use std::num;
 use std::path::Path;
 
-// We derive `Debug` because all types should probably derive `Debug`.
-// This gives us a reasonable human readable description of `CliError` values.
+# // We derive `Debug` because all types should probably derive `Debug`.
+# // This gives us a reasonable human readable description of `CliError` values.
+// 全ての型は `Debug` を導出するべきでしょうから、ここでも `Debug` を導出します。
+// これにより `CliError` 値について、人間が十分理解できる説明を得られます。
 #[derive(Debug)]
 enum CliError {
     Io(io::Error),
@@ -1785,12 +1889,17 @@ fn file_double_verbose<P: AsRef<Path>>(file_path: P) -> Result<i32, CliError> {
 }
 ```
 
-Notice that we still have the calls to `map_err`. Why? Well, recall the
-definitions of [`try!`](#code-try-def) and [`From`](#code-from-def). The
-problem is that there is no `From` impl that allows us to convert from error
-types like `io::Error` and `num::ParseIntError` to our own custom `CliError`.
-Of course, it is easy to fix this! Since we defined `CliError`, we can impl
-`From` with it:
+<!-- Notice that we still have the calls to `map_err`. Why? Well, recall the -->
+<!-- definitions of [`try!`](#code-try-def) and [`From`](#code-from-def). The -->
+<!-- problem is that there is no `From` impl that allows us to convert from error -->
+<!-- types like `io::Error` and `num::ParseIntError` to our own custom `CliError`. -->
+<!-- Of course, it is easy to fix this! Since we defined `CliError`, we can impl -->
+<!-- `From` with it: -->
+`map_err` がまだあることに注目してください。
+なぜって、 [`try!`](#code-try-def) と [`From`](#code-from-def) の定義を思い出してください。
+ここでの問題は `io::Error` や `num::ParseIntError` といったエラー型を、私たち独自の `CliError` に変換できる `From` の実装が無いことです。
+もちろん、これは簡単に直せます！
+`CliError` を定義したわけですから、それに対して `From` を実装できます：
 
 ```rust
 # #[derive(Debug)]
@@ -1811,11 +1920,15 @@ impl From<num::ParseIntError> for CliError {
 }
 ```
 
-All these impls are doing is teaching `From` how to create a `CliError` from
-other error types. In our case, construction is as simple as invoking the
-corresponding value constructor. Indeed, it is *typically* this easy.
+<!-- All these impls are doing is teaching `From` how to create a `CliError` from -->
+<!-- other error types. In our case, construction is as simple as invoking the -->
+<!-- corresponding value constructor. Indeed, it is *typically* this easy. -->
+これらの実装がしていることは、`From` に対して、どうやって他のエラー型を元に `CliError` を作るのかを教えてあげることです。
+このケースでは、単に対応する値コンストラクタを呼ぶことで構築しています。
+本当に *普通は* これくらい簡単にできてしまいます。
 
-We can finally rewrite `file_double`:
+<!-- We can finally rewrite `file_double`: -->
+これでようやく `file_double` を書き直せます：
 
 ```rust
 # use std::io;
@@ -1841,14 +1954,18 @@ fn file_double<P: AsRef<Path>>(file_path: P) -> Result<i32, CliError> {
 }
 ```
 
-The only thing we did here was remove the calls to `map_err`. They are no
-longer needed because the `try!` macro invokes `From::from` on the error value.
-This works because we've provided `From` impls for all the error types that
-could appear.
+<!-- The only thing we did here was remove the calls to `map_err`. They are no -->
+<!-- longer needed because the `try!` macro invokes `From::from` on the error value. -->
+<!-- This works because we've provided `From` impls for all the error types that -->
+<!-- could appear. -->
+ここでしたのは `map_err` を取り除くことだけです。
+それらは `try!` マクロがエラーの値に対して `From::from` を呼ぶので、もう不要になりました。
+これで動くのは、起こりうる全てのエラー型に対して `From` の実装を提供したからです。
 
-If we modified our `file_double` function to perform some other operation, say,
-convert a string to a float, then we'd need to add a new variant to our error
-type:
+<!-- If we modified our `file_double` function to perform some other operation, say, -->
+<!-- convert a string to a float, then we'd need to add a new variant to our error -->
+<!-- type: -->
+もし `file_double` 関数を変更して、なにか他の操作、例えば、文字列を浮動小数点数に変換させたい、と思ったら、エラー型のバリエーションを追加するだけです：
 
 ```rust
 use std::io;
@@ -1861,7 +1978,7 @@ enum CliError {
 }
 ```
 
-And add a new `From` impl:
+<!-- And add a new `From` impl: -->
 
 ```rust
 # enum CliError {
@@ -1879,38 +1996,53 @@ impl From<num::ParseFloatError> for CliError {
 }
 ```
 
-And that's it!
-
-## Advice for library writers
-
-If your library needs to report custom errors, then you should
-probably define your own error type. It's up to you whether or not to
-expose its representation (like
-[`ErrorKind`](../std/io/enum.ErrorKind.html)) or keep it hidden (like
-[`ParseIntError`](../std/num/struct.ParseIntError.html)). Regardless
-of how you do it, it's usually good practice to at least provide some
-information about the error beyond just its `String`
-representation. But certainly, this will vary depending on use cases.
-
-At a minimum, you should probably implement the
-[`Error`](../std/error/trait.Error.html)
-trait. This will give users of your library some minimum flexibility for
-[composing errors](#the-real-try-macro). Implementing the `Error` trait also
-means that users are guaranteed the ability to obtain a string representation
-of an error (because it requires impls for both `fmt::Debug` and
-`fmt::Display`).
-
-Beyond that, it can also be useful to provide implementations of `From` on your
-error types. This allows you (the library author) and your users to
-[compose more detailed errors](#composing-custom-error-types). For example,
-[`csv::Error`](http://burntsushi.net/rustdoc/csv/enum.Error.html)
-provides `From` impls for both `io::Error` and `byteorder::Error`.
-
-Finally, depending on your tastes, you may also want to define a
-[`Result` type alias](#the-result-type-alias-idiom), particularly if your
-library defines a single error type. This is used in the standard library
-for [`io::Result`](../std/io/type.Result.html)
-and [`fmt::Result`](../std/fmt/type.Result.html).
+<!-- And that's it! -->
+これで完成です！
+
+<!-- ## Advice for library writers -->
+## ライブラリ作者たちへのアドバイス
+
+<!-- If your library needs to report custom errors, then you should -->
+<!-- probably define your own error type. It's up to you whether or not to -->
+<!-- expose its representation (like -->
+<!-- [`ErrorKind`](../std/io/enum.ErrorKind.html)) or keep it hidden (like -->
+<!-- [`ParseIntError`](../std/num/struct.ParseIntError.html)). Regardless -->
+<!-- of how you do it, it's usually good practice to at least provide some -->
+<!-- information about the error beyond just its `String` -->
+<!-- representation. But certainly, this will vary depending on use cases. -->
+もし、あなたのライブラリーがカスタマイズされたエラーを報告しなければならないなら、恐らく、独自のエラー型を定義するべきでしょう。
+エラーの表現を表にさらすか（例： [`ErrorKind`](../std/io/enum.ErrorKind.html) ） 、隠しておくか（例： [`ParseIntError`](../std/num/struct.ParseIntError.html) ）は、あなたの自由です。
+いずれかに関係なく、最低でも `String` による表現を超えたエラー情報を提供することが、ほとんどの場合、良い方法となるしょう。
+しかしこれは疑いなく、ユースケースに大きく依存します。
+
+<!-- At a minimum, you should probably implement the -->
+<!-- [`Error`](../std/error/trait.Error.html) -->
+<!-- trait. This will give users of your library some minimum flexibility for -->
+<!-- [composing errors](#the-real-try-macro). Implementing the `Error` trait also -->
+<!-- means that users are guaranteed the ability to obtain a string representation -->
+<!-- of an error (because it requires impls for both `fmt::Debug` and -->
+<!-- `fmt::Display`). -->
+最低でも [`Error`](../std/error/trait.Error.html) トレイトを実装するべきでしょう。
+これにより、ライブラリの利用者に [エラーを合成する](#本当の-try-マクロ) ための、最低ラインの柔軟性を与えます。
+`Error` トレイトを実装することは、利用者がエラーの文字列表現を取得できると保証することにもなります（なぜなら、こうすると `fmt::Debug` と `fmt::Display` の実装が必須になるからです）。
+
+<!-- Beyond that, it can also be useful to provide implementations of `From` on your -->
+<!-- error types. This allows you (the library author) and your users to -->
+<!-- [compose more detailed errors](#composing-custom-error-types). For example, -->
+<!-- [`csv::Error`](http://burntsushi.net/rustdoc/csv/enum.Error.html) -->
+<!-- provides `From` impls for both `io::Error` and `byteorder::Error`. -->
+さらには、あなたのエラー型に対して `From` の実装を提供するのも便利かもしれません。
+このことは、（ライブラリ作者である）あなたと利用者が、 [より詳細なエラーを合成する](#独自のエラー型を合成する) ことを可能にします。
+例えば [`csv::Error`](http://burntsushi.net/rustdoc/csv/enum.Error.html) は `io::Error` と `byteorder::Error` の両方に `From` 実装を提供しています。
+
+<!-- Finally, depending on your tastes, you may also want to define a -->
+<!-- [`Result` type alias](#the-result-type-alias-idiom), particularly if your -->
+<!-- library defines a single error type. This is used in the standard library -->
+<!-- for [`io::Result`](../std/io/type.Result.html) -->
+<!-- and [`fmt::Result`](../std/fmt/type.Result.html). -->
+最後に、お好みで [`Result` 型エイリアス](#result-型エイリアスを用いたイディオム) を定義したくなるかもしれません。
+特にライブラリでエラー型を一つだけ定義している時は当てはまります。
+この方法は標準ライブラリの [`io::Result`](../std/io/type.Result.html) や [`fmt::Result`](../std/fmt/type.Result.html) で用いられています。
 
 # Case study: A program to read population data
 
diff --git a/TranslationTable.md b/TranslationTable.md
index a929c5cd..d07f2daa 100644
--- a/TranslationTable.md
+++ b/TranslationTable.md
@@ -68,6 +68,7 @@
 | ergonomic                      | エルゴノミック（人間にとって扱いやすいもの）
 | error                          | エラー
 | error handling                 | エラーハンドリング
+| existentially quantified type  | 存在量型
 | expression statement           | 式文
 | feature                        | フィーチャ
 | foreign                        | 他言語

From 1efe4a90c7b9c15a4fa7e57885a7c17773feee09 Mon Sep 17 00:00:00 2001
From: Tatsuya Kawano <tatsuya@hibaridb.org>
Date: Sat, 20 Feb 2016 12:13:24 +0800
Subject: [PATCH 2/6] error-handling - apply review comments

 Apply review comment
---
 1.6/ja/book/error-handling.md | 58 +++++++++++++++++------------------
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/1.6/ja/book/error-handling.md b/1.6/ja/book/error-handling.md
index f2e58ebc..73d2cab2 100644
--- a/1.6/ja/book/error-handling.md
+++ b/1.6/ja/book/error-handling.md
@@ -75,7 +75,7 @@ Rustでは戻り値を使います。
 * [複数のエラー型を扱う](#複数のエラー型を扱う)
     * [`Option` と `Result` を合成する](#option-と-result-を合成する)
     * [コンビネータの限界](#コンビネータの限界)
-    * [早期のリターン](#早期のリターン)
+    * [早期リターン](#早期リターン)
     * [`try!` マクロ](#try-マクロ)
     * [独自のエラー型を定義する](#独自のエラー型を定義する)
 * [標準ライブラリのトレイトによるエラー処理](#標準ライブラリのトレイトによるエラー処理)
@@ -182,7 +182,7 @@ fn main() {
 <!-- conditions, yet, the program does not include an explicit call to `panic` like -->
 <!-- the first example. This is because the -->
 <!-- panic is embedded in the calls to `unwrap`. -->
-先ほどの例で、プログラムが2つのエラー条件のいずれかを満たした時に、パニックすると言いました。
+先ほどの例で、プログラムが2つのエラー条件のいずれかを満たしたときに、パニックすると言いました。
 でもこのプログラムは、最初の例とは違って明示的に `panic` を呼び出してはいません。
 実はパニックは `unwrap` の呼び出しの中に埋め込まれているのです。
 
@@ -191,7 +191,7 @@ fn main() {
 <!-- It would be better if we just showed the code for unwrapping because it is so -->
 <!-- simple, but to do that, we will first need to explore the `Option` and `Result` -->
 <!-- types. Both of these types have a method called `unwrap` defined on them. -->
-Rustでなにかを「アンラップする」時、こう言っているのと同じです。
+Rustでなにかを「アンラップする」とき、こう言っているのと同じです。
 「計算結果を取り出しなさい。もしエラーになっていたのなら、パニックを起こしてプログラムを終了させなさい。」
 アンラップのコードはとてもシンプルなので、多分、それを見せたほうが早いでしょう。
 でもそのためには、まず `Option` と `Result` 型について調べる必要があります。
@@ -244,7 +244,7 @@ fn find(haystack: &str, needle: char) -> Option<usize> {
 <!-- with the type `fn<T>(value: T) -> Option<T>`. Correspondingly, `None` is also a -->
 <!-- value constructor, except it has no arguments. You can think of `None` as a -->
 <!-- function with the type `fn<T>() -> Option<T>`. -->
-この関数がマッチする文字を見つけた時、単に `offset` を返すだけではないことに注目してください。
+この関数がマッチする文字を見つけたとき、単に `offset` を返すだけではないことに注目してください。
 その代わりに `Some(offset)` を返します。
 `Some` は `Option` 型の *値コンストラクタ* の一つです。
 これは `fn<T>(value: T) -> Option<T>` という型の関数だと考えることもできます。
@@ -282,7 +282,7 @@ fn main() {
 <!-- `None` instead of `Some(t)`. -->
 このコードは `find` 関数が返した `Option<usize>` の *場合分け* に、 [パターンマッチ][1] を使っています。
 実のところ、場合分けが、`Option<T>` に格納された値を取り出すための唯一の方法なのです。
-これは、`Option<T>` が `Some(t)` ではなく `None` だった時、プログラマであるあなたが、このケースに対処しなければならないことを意味します。
+これは、`Option<T>` が `Some(t)` ではなく `None` だったとき、プログラマであるあなたが、このケースに対処しなければならないことを意味します。
 
 <!-- But wait, what about `unwrap`,which we used [`previously`](#code-unwrap-double)? -->
 <!-- There was no case analysis there! Instead, the case analysis was put inside the -->
@@ -421,8 +421,8 @@ fn extension(file_name: &str) -> Option<&str> {
 <!-- the extension of a file is `rs` even if none is present. As you might imagine, -->
 <!-- the case analysis for this is not specific to file extensions - it can work -->
 <!-- with any `Option<T>`: -->
-もう一つの共通のパターンは、`Option` の値が `None` だった時のデフォルト値を与えることです。
-例えばファイルの拡張子がない時は、それを `rs` とみなすようなプログラムを書きたくなるかもしれません。
+もう一つの共通のパターンは、`Option` の値が `None` だったときのデフォルト値を与えることです。
+例えばファイルの拡張子がないときは、それを `rs` とみなすようなプログラムを書きたくなるかもしれません。
 ご想像の通り、このような場合分けはファイルの拡張子に特有のものではありません。
 どんな `Option<T>` でも使えるでしょう：
 
@@ -554,7 +554,7 @@ fn file_path_ext(file_path: &str) -> Option<&str> {
 <!-- remove choices because they will panic if `Option<T>` is `None`. -->
 コンビネータは明示的な場合分けを減らしてくれるので、 `Option` のような型をエルゴノミックにします。
 またこれらは *不在の可能性* を、呼び出し元がそれに合った方法で扱えるようにするので、合成可能だといえます。
-`unwrap` のようなメソッドは、 `Option<T>` が `None` の時にパニックを起こすので、このような選択の機会を与えません。
+`unwrap` のようなメソッドは、 `Option<T>` が `None` のときにパニックを起こすので、このような選択の機会を与えません。
 
 <!-- ## The `Result` type -->
 ## `Result` 型
@@ -707,7 +707,7 @@ impl str {
 それも悪いやり方ではありませんが、実装の内側では *なぜ* 文字列が整数としてパースできなかったを、ちゃんと区別しています。
 （空の文字列だったのか、有効な数字でなかったのか、大きすぎたり、小さすぎたりしたのか。）
 従って、`Result` を使ってより多くの情報を提供するほうが、単に「不在」を示すことよりも理にかなっています。
-今後、もし `Option` と `Result` のどちらを選ぶという事態に遭遇した時は、このような理由付けのやり方を真似てみてください。
+今後、もし `Option` と `Result` のどちらを選ぶという事態に遭遇したときは、このような理由付けのやり方を真似てみてください。
 もし詳細なエラー情報を提供できるのなら、多分、それをしたほうがいいでしょう。
 （後ほど別の例もお見せます。）
 
@@ -855,7 +855,7 @@ fn double_number(number_str: &str) -> Result<i32> {
 <!--   appealing. -->
 * **即興で書いたサンプルコード。**
   サンプルコードや簡単なプログラムを書いていて、エラーハンドリングが単に重要でないこともあります。
-  このような時に `unwrap` の便利さは、とても魅力的に映るでしょう。
+  このようなときに `unwrap` の便利さは、とても魅力的に映るでしょう。
   これに打ち勝つのは難しいことです。
 
 <!-- * **When panicking indicates a bug in the program.** When the invariants of -->
@@ -863,8 +863,8 @@ fn double_number(number_str: &str) -> Result<i32> {
 <!--   from an empty stack), then panicking can be permissible. This is because it -->
 <!--   exposes a bug in your program. This can be explicit, like from an `assert!` -->
 <!--   failing, or it could be because your index into an array was out of bounds. -->
-* **パニックがプログラムのバグの兆候となる時。**
-  コードの中の不変条件が、ある特定のケースの発生を未然に防ぐ時（例えば、空のスタックから取り出そうとしたなど）、パニックを起こしても差し支えありません。
+* **パニックがプログラムのバグの兆候となるとき。**
+  コードの中の不変条件が、ある特定のケースの発生を未然に防ぐとき（例えば、空のスタックから取り出そうとしたなど）、パニックを起こしても差し支えありません。
   なぜなら、そうすることでプログラムに潜むバグが明るみに出るからです。
   これは `assert!` の失敗のような明示的な要因によるものだったり、配列のインデックスが境界から外れたからだったりします。
 
@@ -876,7 +876,7 @@ fn double_number(number_str: &str) -> Result<i32> {
 <!-- a bit nicer to deal with, since it will show your message instead of -->
 <!-- “callaed unwrap on a `None` value.” -->
 これは多分、完全なリストではないでしょう。
-さらに `Option` を使う時は、ほとんどの場合で [`expect`](../std/option/enum.Option.html#method.expect) メソッドを使う方がいいでしょう。
+さらに `Option` を使うときは、ほとんどの場合で [`expect`](../std/option/enum.Option.html#method.expect) メソッドを使う方がいいでしょう。
 `expect` は `unwrap` とほぼ同じことをしますが、 `expect` では与えられたメッセージを表示するところが異なります。
 この方が結果として起こったパニックを、少し扱いやすいものにします。
 なぜなら「 `None` な値に対してアンラップが呼ばれました」というメッセージの代わりに、指定したメッセージが表示されるからです。
@@ -927,7 +927,7 @@ fn double_number(number_str: &str) -> Result<i32> {
 <!-- or can we continue using combinators? -->
 もちろん現実のコードは、いつもこんなにクリーンではありません。
 時には `Option` 型と `Result` 型が混在していることもあるでしょう。
-そんな時は、明示的な場合分けに頼るしかないのでしょうか？
+そんなときは、明示的な場合分けに頼るしかないのでしょうか？
 それとも、コンビネータを使い続けることができるのでしょうか？
 
 <!-- For now, let's revisit one of the first examples in this chapter: -->
@@ -958,7 +958,7 @@ fn main() {
 <!-- could just use a `String` to describe the error. Let's try: -->
 ここでの問題は `argv.nth(1)` が `Option` を返すのに、 `arg.parse()` は `Result` を返すことです。
 これらを直接合成することはできません。
-`Option` と `Result` の両方に出会った時の *通常の* 解決策は `Option` を `Result` に変換することです。
+`Option` と `Result` の両方に出会ったときの *通常の* 解決策は `Option` を `Result` に変換することです。
 この例で（`env::args()` が）コマンドライン引数を返さなかったということは、ユーザーがプログラムを正しく起動しなかったことを意味します。
 エラーの理由を示すために、単純に `String` を使うこともできます。
 試してみましょう：
@@ -995,7 +995,7 @@ fn main() {
 この例では、いくつか新しいことがあります。
 ひとつ目は [`Option::ok_or`](../std/option/enum.Option.html#method.ok_or) コンビネータを使ったことです。
 これは `Option` を `Result` へ変換する方法の一つです。
-変換には `Option` が `None` の時に使われるエラーを指定する必要があります。
+変換には `Option` が `None` のときに使われるエラーを指定する必要があります。
 他のコンビネータと同様に、その定義はとてもシンプルです：
 
 ```rust
@@ -1084,7 +1084,7 @@ fn main() {
 <!-- 2. A problem reading data from the file. -->
 <!-- 3. A problem parsing the data as a number. -->
 1. ファイルを開くときの問題
-2. ファイルからデータを読み込む時の問題
+2. ファイルからデータを読み込むときの問題
 3. データを数値としてパースするときの問題
 
 <!-- The first two problems are described via the -->
@@ -1117,7 +1117,7 @@ fn main() {
 <!-- type from `i32` to something else. -->
 まず最初に `file_double` 関数をリファクタリングしましょう。
 この関数を、このプログラムの他の構成要素と合成可能にするためには、上記の問題のいずれかに遭遇しても、パニック *しない* ようにしなければなりません。
-これは実質的には、なにかの操作に失敗した時に、この関数が *エラーを返すべき* であることを意味します。
+これは実質的には、なにかの操作に失敗したときに、この関数が *エラーを返すべき* であることを意味します。
 ここでの問題は、`file_double` のリターン型が `i32` であるため、エラーの報告には全く役立たないことです。
 従ってリターン型を `i32` から別の何かに変えることから始めましょう。
 
@@ -1133,7 +1133,7 @@ fn main() {
 `Option` なら間違いなく簡単に使えます。
 もし3つのエラーのどれかが起こったら、単に `None` を返せばいいのですから。
 これはたしかに動きますし、 *パニックを起こすよりは良くなっています* 。
-とはいえ、もっと良くすることもだってできます。
+とはいえ、もっと良くすることもできます。
 `Option` の代わりに、発生したエラーについての詳細を渡すべきでしょう。
 ここでは *エラーの可能性* を示したいのですから、`Result<i32, E>` を使うのがよさそうです。
 でも `E` を何にしたらいいのでしょうか？
@@ -1195,7 +1195,7 @@ fn main() {
 <!-- example, the very last call to `map` multiplies the `Ok(...)` value (which is -->
 <!-- an `i32`) by `2`. If an error had occurred before that point, this operation -->
 <!-- would have been skipped because of how `map` is defined. -->
-`map` は `Result` の値が `Ok(...)` の時に関数を適用するために使います。
+`map` は `Result` の値が `Ok(...)` のときに関数を適用するために使います。
 例えば、一番最後の `map` の呼び出しは、`Ok(...)` の値（ `i32` 型）に `2` を掛けます。
 もし、これより前にエラーが起きたなら、この操作は `map` の定義に従ってスキップされます。
 
@@ -1205,7 +1205,7 @@ fn main() {
 <!-- both `io::Error` and `num::ParseIntError` implement `ToString`, we can call the -->
 <!-- `to_string()` method to convert them. -->
 `map_err` は全体をうまく動かすための仕掛けです。
-`map_err` は `map` に似ていますが、 `Result` の値が `Err(...)` の時に関数を適用するところが異なります。
+`map_err` は `map` に似ていますが、 `Result` の値が `Err(...)` のときに関数を適用するところが異なります。
 今回の場合は、全てのエラーを `String` という同一の型に変換する予定でした。
 `io::Error` と `num::ParseIntError` の両方が `ToString` を実装していたので、 `to_string()` メソッドを呼ぶことで変換できました。
 
@@ -1214,18 +1214,18 @@ fn main() {
 <!-- returns. -->
 説明し終わった後でも、このコードは難解なままです。
 コンビネータの使い方をマスターすることは重要ですが、コンビネータには限界もあるのです。
-次は、早期のリターンと呼ばれる、別のアプローチを試してみましょう。
+次は、早期リターンと呼ばれる、別のアプローチを試してみましょう。
 
 <!-- ## Early returns -->
-## 早期のリターン
+## 早期リターン
 
 <!-- I'd like to take the code from the previous section and rewrite it using *early -->
 <!-- returns*. Early returns let you exit the function early. We can't return early -->
 <!-- in `file_double` from inside another closure, so we'll need to revert back to -->
 <!-- explicit case analysis. -->
-前の節で使ったコードを、 *早期のリターン* を使って書き直してみようと思います。
-早期のリターンとは、関数の途中で抜けることを指します。
-`file_double` のクロージャの中にいる間は、早期のリターンはできないので、明示的な場合分けまでいったん戻る必要があります。
+前の節で使ったコードを、 *早期リターン* を使って書き直してみようと思います。
+早期リターンとは、関数の途中で抜けることを指します。
+`file_double` のクロージャの中にいる間は、早期リターンはできないので、明示的な場合分けまでいったん戻る必要があります。
 
 ```rust
 use std::fs::File;
@@ -1403,7 +1403,7 @@ fn main() {
 <!-- with *structured data*. We endeavor to not drop information from underlying -->
 <!-- errors in case the caller wants to inspect the details. -->
 ファイルから整数値を取り出す例で `String` をエラー型として用いた代わりに、独自のエラー型を定義し、 *構造化されたデータ* によってエラー内容を表すことができます。
-呼び出し元が詳細を検査したい時に備え、大元のエラーについての情報を取りこぼさないよう、努力してみましょう。
+呼び出し元が詳細を検査したいときに備え、大元のエラーについての情報を取りこぼさないよう、努力してみましょう。
 
 <!-- The ideal way to represent *one of many possibilities* is to define our own -->
 <!-- sum type using `enum`. In our case, an error is either an `io::Error` or a -->
@@ -1471,8 +1471,8 @@ fn main() {
 <!-- will do in a pinch, particularly if you're writing an application. If you're -->
 <!-- writing a library, defining your own error type should be strongly preferred so -->
 <!-- that you don't remove choices from the caller unnecessarily. -->
-目安となる方法は独自のエラー型を定義することですが、 `String` エラー型も、いざという時に役立ちます。
-特にアプリケーションを書いている時などはそうです。
+目安となる方法は独自のエラー型を定義することですが、 `String` エラー型も、いざというときに役立ちます。
+特にアプリケーションを書いているときなどはそうです。
 もしライブラリを書いているのなら、呼び出し元の選択肢を理由もなく奪わないために、独自のエラー型を定義することを強く推奨します。
 
 <!-- # Standard library traits used for error handling -->

From 61492cef295549f75f03447ce53673531f2b2026 Mon Sep 17 00:00:00 2001
From: Tatsuya Kawano <tatsuya@hibaridb.org>
Date: Sat, 20 Feb 2016 13:12:13 +0800
Subject: [PATCH 3/6] error-handling - brush up the translation

---
 1.6/ja/book/error-handling.md | 55 ++++++++++++++++++-----------------
 1 file changed, 28 insertions(+), 27 deletions(-)

diff --git a/1.6/ja/book/error-handling.md b/1.6/ja/book/error-handling.md
index 73d2cab2..17df3bd1 100644
--- a/1.6/ja/book/error-handling.md
+++ b/1.6/ja/book/error-handling.md
@@ -1513,18 +1513,19 @@ trait Error: Debug + Display {
 <!-- types that represent errors. This will prove useful for writing composable code -->
 <!-- as we'll see later. Otherwise, the trait allows you to do at least the -->
 <!-- following things: -->
-このトレイトはエラーを表す *全て* の型で実装されることを目的としており、ごく一般的なデフォルト実装を持ちます。
-この後すぐ見るように、このことが合成可能なコードを書くのに役立っています。
-一方で、このトレイトは最低でも以下のようなカスタマイズを可能にします：
+このトレイトは極めて一般的です。
+なぜなら、エラーを表す *全て* の型で実装されることを目的としているからです。
+この後すぐ見るように、このことが合成可能なコードを書くのに間違いなく役立ちます。
+それ以外にも、このトレイトでは最低でも以下のようなことができます：
 
 <!-- * Obtain a `Debug` representation of the error. -->
 <!-- * Obtain a user-facing `Display` representation of the error. -->
 <!-- * Obtain a short description of the error (via the `description` method). -->
 <!-- * Inspect the causal chain of an error, if one exists (via the `cause` method). -->
-* エラーの `Debug` 表現を取得する
-* エラーのユーザー向けの `Display` 表現を取得する
-* エラーの簡単な説明を取得する（`cause` メソッド経由）
-* エラーの因果関係のチェーンが提供されているなら、それを調べる（`cause` メソッド経由）
+* エラーの `Debug` 表現を取得する。
+* エラーのユーザー向け `Display` 表現を取得する。
+* エラーの簡単な説明を取得する（`cause` メソッド経由）。
+* エラーの因果関係のチェーンが提供されているなら、それを調べる（`cause` メソッド経由）。
 
 <!-- The first two are a result of `Error` requiring impls for both `Debug` and -->
 <!-- `Display`. The latter two are from the two methods defined on `Error`. The -->
@@ -1539,13 +1540,13 @@ trait Error: Debug + Display {
 `Error` の強力さは、実際に全てのエラー型が `Error` を実装していることから来ています。
 このことは、全てのエラーを1つの [トレイトオブジェクト](../book/trait-objects.html) として存在量化(existentially quantify) できることを意味します。
 これは `Box<Error>` または `&Error` と書くことで表明できます。
-まさに `cause` メソッドは `&Error` を返し、それ自身がトレイトオブジェクトです。
-`Error` トレイトのトレイトオブジェクトとしての用例については、後ほど再び取り上げます。
+実際に `cause` メソッドは `&Error` を返し、これ自体はトレイトオブジェクトです。
+`Error` トレイトのトレイトオブジェクトとしての用例については、後ほど再び取りあげます。
 
 <!-- For now, it suffices to show an example implementing the `Error` trait. Let's -->
 <!-- use the error type we defined in the -->
 <!-- [previous section](#defining-your-own-error-type): -->
-`Error` トレイトの実装例を見せるには十分でしょう。
+`Error` トレイトの実装例を見せるには、いまはこのくらいで十分でしょう。
 [前の節](#独自のエラー型を定義する) で定義したエラー型を使ってみましょう：
 
 ```rust
@@ -1567,13 +1568,13 @@ enum CliError {
 <!-- occurring: an error dealing with I/O or an error converting a string to a -->
 <!-- number. The error could represent as many error types as you want by adding new -->
 <!-- variants to the `enum` definition. -->
-このエラー型は2種類のエラー、つまり、IOを扱っている時のエラー、または、文字列を通知に変換するときのエラーが起こる可能性を示しています。
-`enum` 定義にバリエーションを加えることで、エラーの種類をいくらでも表現できます。
+このエラー型は2種類のエラー、つまり、IOを扱っているときのエラー、または、文字列を通知に変換するときのエラーが起こる可能性を示しています。
+`enum` 定義のバリアントを増やせば、エラーの種類をいくらでも表現できます。
 
 <!-- Implementing `Error` is pretty straight-forward. It's mostly going to be a lot -->
 <!-- explicit case analysis. -->
 `Error` を実装するのは実に単純な作業です。
-ほとんどの場合は明示的な場合分けの繰り返しになります。
+大抵は明示的な場合分けの繰り返しになります。
 
 ```rust,ignore
 use std::error;
@@ -1625,7 +1626,7 @@ impl error::Error for CliError {
 <!-- different error types and satisfy the contracts defined for `description` and -->
 <!-- `cause`. -->
 これは極めて典型的な `Error` の実装だということに留意してください。
-このように異なるエラー型にマッチさせて、`description` と `cause` のコントラクトを満たします。
+このように、それぞれのエラー型にマッチさせて、`description` と `cause` のコントラクトを満たします。
 
 <!-- ## The `From` trait -->
 ## `From` トレイト
@@ -1652,7 +1653,7 @@ trait From<T> {
 嬉しいくらい簡単でしょ？
 `From` は、ある特定の型 `T` から違う型へ変換するための汎用的な方法を提供するので大変便利です
 （この場合の「違う型」とは実装の対象、つまり `Self` です）。
-`From` で最も重要なのは [標準ライブラリで提供される一連の実装です](../std/convert/trait.From.html)。
+`From` を支えているのは [標準ライブラリで提供される一連の実装です](../std/convert/trait.From.html)。
 
 <!-- Here are a few simple examples demonstrating how `From` works: -->
 `From` がどのように動くか、いくつかの例を使って紹介しましょう：
@@ -1677,7 +1678,7 @@ impl<'a, E: Error + 'a> From<E> for Box<Error + 'a>
 <!-- trait object `Box<Error>`. This may not seem terribly surprising, but it is -->
 <!-- useful in a generic context. -->
 この実装では、 `Error` を実装した *全て* の型は、トレイトオブジェクト `Box<Error>` に変換できると言っています。
-これは、あまり驚くほどのものには見えませんが、一般的な状況では有用です。
+これは、驚きに値するものには見えないかもしれませんが、一般的なコンテキストで有用なのです。
 
 <!-- Remember the two errors we were dealing with previously? Specifically, -->
 <!-- `io::Error` and `num::ParseIntError`. Since both impl `Error`, they work with -->
@@ -1710,7 +1711,7 @@ let err2: Box<Error> = From::from(parse_err);
 <!-- Additionally, we constructed `err1` and `err2` using precisely the same -->
 <!-- function call: `From::from`. This is because `From::from` is overloaded on both -->
 <!-- its argument and its return type. -->
-ここに認識すべき、本当に重要なパターンがあります。
+ここに気づくべき、本当に重要なパターンがあります。
 `err1` と `err2` の両方ともが *同じ型* になっているのです。
 なぜなら、それらが存在量型、つまり、トレイトオブジェクトだからです。
 特にそれらの背後の型は、コンパイラーの知識から *消去されます* ので、 `err1` と `err2` が本当に同じに見えるのです。
@@ -1720,11 +1721,11 @@ let err2: Box<Error> = From::from(parse_err);
 <!-- This pattern is important because it solves a problem we had earlier: it gives -->
 <!-- us a way to reliably convert errors to the same type using the same function. -->
 このパターンは重要です。
-なぜなら、私たちが以前抱えていた問題を解決するからです：
+なぜなら、私たちが前から抱えていた問題を解決するからです：
 同じ関数を使って、エラーを同一の型に変換する、確かな方法を提供するからです。
 
 <!-- Time to revisit an old friend; the `try!` macro. -->
-いよいよ、私たちの旧友 `try!` マクロを再訪する時が訪れました。
+いよいよ、私たちの旧友 `try!` マクロを再訪するときが訪れました。
 
 <!-- ## The real `try!` macro -->
 ## 本当の `try!` マクロ
@@ -1760,7 +1761,7 @@ macro_rules! try {
 <!-- 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 -->
 <!-- you automatic type conversion for free. -->
-ここには、たった一つですが、大きな違いがあります：
+文面上はわずかですが、非常に大きな違いがあります：
 エラーの値は `From::from` を経て渡されるのです。
 これにより `try!` マクロは、はるかに強力になります。
 なぜなら、自動的な型変換をただで手に入れられるのですから。
@@ -1822,7 +1823,7 @@ fn file_double<P: AsRef<Path>>(file_path: P) -> Result<i32, Box<Error>> {
 
 <!-- When all three things are combined, we get code that is unencumbered by -->
 <!-- combinators, calls to `unwrap` or case analysis. -->
-これら3つが一つになった時、コンビネータ、 `unwrap` の呼び出し、場合分けなどの邪魔者を排除したコードが得られるのです。
+これら3つが一つになったとき、コンビネータ、 `unwrap` の呼び出し、場合分けなどの邪魔者を排除したコードが得られるのです。
 
 <!-- There's one little nit left: the `Box<Error>` type is *opaque*. If we -->
 <!-- return a `Box<Error>` to the caller, the caller can't (easily) inspect -->
@@ -1845,7 +1846,7 @@ fn file_double<P: AsRef<Path>>(file_path: P) -> Result<i32, Box<Error>> {
 この方法が有効なシナリオもありますが、[この章で扱う範囲を超えています](https://crates.io/crates/error) ）
 
 <!-- It's time to revisit our custom `CliError` type and tie everything together. -->
-では、私たちのカスタムエラー型 `CliErro` に戻って、全てを一つにまとめ上げましょう。
+では、私たちのカスタムエラー型 `CliError` に戻って、全てを一つにまとめ上げましょう。
 
 <!-- ## Composing custom error types -->
 ## 独自のエラー型を合成する
@@ -1856,7 +1857,7 @@ fn file_double<P: AsRef<Path>>(file_path: P) -> Result<i32, Box<Error>> {
 <!-- is opaque to callers. -->
 最後の説では `try!` マクロの本当の定義を確認し、それが `From::from` をエラーの値に対して呼ぶことで、自動的な型変換をする様子を見ました。
 特にそこでは、エラーを `Box<Error>` に変換しました。
-これはたしかに動きますが、呼び出し元にとって型がオペークになってしまいました。
+これはたしかに動きますが、呼び出し元にとって、型がオペークになってしまいました。
 
 <!-- To fix this, we use the same remedy that we're already familiar with: a custom -->
 <!-- error type. Once again, here is the code that reads the contents of a file and -->
@@ -1965,7 +1966,7 @@ fn file_double<P: AsRef<Path>>(file_path: P) -> Result<i32, CliError> {
 <!-- If we modified our `file_double` function to perform some other operation, say, -->
 <!-- convert a string to a float, then we'd need to add a new variant to our error -->
 <!-- type: -->
-もし `file_double` 関数を変更して、なにか他の操作、例えば、文字列を浮動小数点数に変換させたい、と思ったら、エラー型のバリエーションを追加するだけです：
+もし `file_double` 関数を変更して、なにか他の操作、例えば、文字列を浮動小数点数に変換させたいと思ったら、エラー型のバリアントを追加するだけです：
 
 ```rust
 use std::io;
@@ -2010,10 +2011,10 @@ impl From<num::ParseFloatError> for CliError {
 <!-- of how you do it, it's usually good practice to at least provide some -->
 <!-- information about the error beyond just its `String` -->
 <!-- representation. But certainly, this will vary depending on use cases. -->
-もし、あなたのライブラリーがカスタマイズされたエラーを報告しなければならないなら、恐らく、独自のエラー型を定義するべきでしょう。
+もし、あなたのライブラリがカスタマイズされたエラーを報告しなければならないなら、恐らく、独自のエラー型を定義するべきでしょう。
 エラーの表現を表にさらすか（例： [`ErrorKind`](../std/io/enum.ErrorKind.html) ） 、隠しておくか（例： [`ParseIntError`](../std/num/struct.ParseIntError.html) ）は、あなたの自由です。
 いずれかに関係なく、最低でも `String` による表現を超えたエラー情報を提供することが、ほとんどの場合、良い方法となるしょう。
-しかしこれは疑いなく、ユースケースに大きく依存します。
+しかしこれは紛れもなく、ユースケースに深く依存します。
 
 <!-- At a minimum, you should probably implement the -->
 <!-- [`Error`](../std/error/trait.Error.html) -->
@@ -2041,7 +2042,7 @@ impl From<num::ParseFloatError> for CliError {
 <!-- for [`io::Result`](../std/io/type.Result.html) -->
 <!-- and [`fmt::Result`](../std/fmt/type.Result.html). -->
 最後に、お好みで [`Result` 型エイリアス](#result-型エイリアスを用いたイディオム) を定義したくなるかもしれません。
-特にライブラリでエラー型を一つだけ定義している時は当てはまります。
+特にライブラリでエラー型を一つだけ定義しているときは当てはまります。
 この方法は標準ライブラリの [`io::Result`](../std/io/type.Result.html) や [`fmt::Result`](../std/fmt/type.Result.html) で用いられています。
 
 # Case study: A program to read population data

From c38528bd55b435171f9470aa07963114a125d94e Mon Sep 17 00:00:00 2001
From: Tatsuya Kawano <tatsuya@hibaridb.org>
Date: Sat, 20 Feb 2016 13:55:08 +0800
Subject: [PATCH 4/6] error-handling - add translation for one missing
 sentence.

---
 1.6/ja/book/error-handling.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/1.6/ja/book/error-handling.md b/1.6/ja/book/error-handling.md
index 17df3bd1..68d0ebbd 100644
--- a/1.6/ja/book/error-handling.md
+++ b/1.6/ja/book/error-handling.md
@@ -1980,6 +1980,7 @@ enum CliError {
 ```
 
 <!-- And add a new `From` impl: -->
+そして、新しい `From` 実装を追加します：
 
 ```rust
 # enum CliError {

From ec843903b8f8e38e37876862f3fcddf1b07ca5e7 Mon Sep 17 00:00:00 2001
From: Tatsuya Kawano <tatsuya@hibaridb.org>
Date: Sat, 20 Feb 2016 14:29:38 +0800
Subject: [PATCH 5/6] error-handling - fix a typo

---
 1.6/ja/book/error-handling.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/1.6/ja/book/error-handling.md b/1.6/ja/book/error-handling.md
index 68d0ebbd..489596e8 100644
--- a/1.6/ja/book/error-handling.md
+++ b/1.6/ja/book/error-handling.md
@@ -1524,7 +1524,7 @@ trait Error: Debug + Display {
 <!-- * Inspect the causal chain of an error, if one exists (via the `cause` method). -->
 * エラーの `Debug` 表現を取得する。
 * エラーのユーザー向け `Display` 表現を取得する。
-* エラーの簡単な説明を取得する（`cause` メソッド経由）。
+* エラーの簡単な説明を取得する（`description` メソッド経由）。
 * エラーの因果関係のチェーンが提供されているなら、それを調べる（`cause` メソッド経由）。
 
 <!-- The first two are a result of `Error` requiring impls for both `Debug` and -->

From df13c9746f3eb093dbf593bef3a2205b6ff20448 Mon Sep 17 00:00:00 2001
From: Tatsuya Kawano <tatsuya@hibaridb.org>
Date: Sun, 21 Feb 2016 18:09:56 +0800
Subject: [PATCH 6/6] error-handling - brust up translation

---
 1.6/ja/book/error-handling.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/1.6/ja/book/error-handling.md b/1.6/ja/book/error-handling.md
index 489596e8..c4349fc5 100644
--- a/1.6/ja/book/error-handling.md
+++ b/1.6/ja/book/error-handling.md
@@ -1846,7 +1846,7 @@ fn file_double<P: AsRef<Path>>(file_path: P) -> Result<i32, Box<Error>> {
 この方法が有効なシナリオもありますが、[この章で扱う範囲を超えています](https://crates.io/crates/error) ）
 
 <!-- It's time to revisit our custom `CliError` type and tie everything together. -->
-では、私たちのカスタムエラー型 `CliError` に戻って、全てを一つにまとめ上げましょう。
+では、私たちの独自のエラー型 `CliError` に戻って、全てを一つにまとめ上げましょう。
 
 <!-- ## Composing custom error types -->
 ## 独自のエラー型を合成する