translate README and read more of 2.1

README.japanese.md

@@ -116,13 +116,13 @@
 
 # `2. エラーハンドリングのプラクティス`
 
-## ![✔] 2.1 Use Async-Await or promises for async error handling
+## ![✔] 2.1 非同期エラーハンドリングに Async-Await または promises を使う
 
-**TL;DR:** Handling async errors in callback style is probably the fastest way to hell (a.k.a the pyramid of doom). The best gift you can give to your code is using a reputable promise library or async-await instead which enables a much more compact and familiar code syntax like try-catch
+**TL;DR:** コールバックスタイルで非同期エラーを処理することは、おそらく地獄への最短経路でしょう（Pyramid of doom として知られています）。あなたができるコードへの最高の贈り物は、信頼できる promise ライブラリや async-await を使うことです。これらは、try-catch のような、よりコンパクトで親しみやすいコードシンタックスを可能にします。
 
-**Otherwise:** Node.js callback style, function(err, response), is a promising way to un-maintainable code due to the mix of error handling with casual code, excessive nesting, and awkward coding patterns
+**さもなければ:** Node.js のコールバックスタイル、つまり function(err, response) を利用することは、正常な処理を行うコードとエラーハンドリングの混同、過剰なネスト構造、そして厄介なコーディングパターンが原因となって、メンテナンス性の低いコードにつながります。
 
-🔗 [**Read More: avoiding callbacks**](/sections/errorhandling/asyncerrorhandling.md)
+🔗 [**さらに読む: コールバック関数の利用を避ける**](/sections/errorhandling/asyncerrorhandling.md)
 
 <br/><br/>
 

sections/errorhandling/asyncerrorhandling.japanese.md

@@ -1,10 +1,10 @@
-# Use Async-Await or promises for async error handling
+# 非同期エラーハンドリングに Async-Await または promises を使う
 
-### One Paragraph Explainer
+### 一段落説明
 
-Callbacks don’t scale well since most programmers are not familiar with them. They force to check errors all over, deal with nasty code nesting and make it difficult to reason about the code flow. Promise libraries like BlueBird, async, and Q pack a standard code style using RETURN and THROW to control the program flow. Specifically, they support the favorite try-catch error handling style which allows freeing the main code path from dealing with errors in every function
+コールバックはあまりスケールしません。なぜなら、ほとんどのプログラマーはコールバックに馴染みがないからです。コールバックによって、エラーをくまなくチェックすることが強制され、厄介なコードの入れ子構造を扱うことになり、またコードのフローを推測することが困難になります。BlueBird や async、そして Q といった promise ライブラリは、RETURN や THROW を使ってプログラムのフローを制御している標準コードを包み込みます。特にそれらのライブラリは、みなの大好きな try-catch エラーハンドリングスタイルをサポートしており、それぞれの関数においてメインコードをエラー処理と分けて扱うことを可能にしています。
 
-### Code Example – using promises to catch errors
+### コード例 – エラーの捕捉に promises を使う
 
 ```javascript
 return functionA()
@@ -16,7 +16,7 @@ return functionA()
 ```
 
 
-### Code Example - using async/await to catch errors
+### コード例 - エラーの捕捉に async/await を使う
 
 ```javascript
 async function executeAsyncTask () {
@@ -34,7 +34,7 @@ async function executeAsyncTask () {
 }
 ```
 
-### Anti pattern code example – callback style error handling
+### アンチパターン – コールバックスタイルのエラーハンドリング
 
 <details>
 <summary><strong>Javascript</strong></summary>
@@ -42,14 +42,14 @@ async function executeAsyncTask () {
 ```javascript
 getData(someParameter, function(err, result) {
     if(err !== null) {
-        // do something like calling the given callback function and pass the error
+        // 渡されたコールバック関数を呼び出してエラーを渡す、といったことをします
         getMoreData(a, function(err, result) {
             if(err !== null) {
-                // do something like calling the given callback function and pass the error
+                // 渡されたコールバック関数を呼び出してエラーを渡す、といったことをします
                 getMoreData(b, function(c) {
                     getMoreData(d, function(e) {
                         if(err !== null ) {
-                            // you get the idea?
+                            // もうおわかりですよね？
                         }
                     })
                 });
@@ -66,14 +66,14 @@ getData(someParameter, function(err, result) {
 ```typescript
 getData(someParameter, function(err: Error | null, resultA: ResultA) {
   if(err !== null) {
-    // do something like calling the given callback function and pass the error
+    // 渡されたコールバック関数を呼び出してエラーを渡す、といったことをします
     getMoreData(resultA, function(err: Error | null, resultB: ResultB) {
       if(err !== null) {
-        // do something like calling the given callback function and pass the error
+        // 渡されたコールバック関数を呼び出してエラーを渡す、といったことをします
         getMoreData(resultB, function(resultC: ResultC) {
           getMoreData(resultC, function(err: Error | null, d: ResultD) {
             if(err !== null) {
-              // you get the idea?
+              // もうおわかりですよね？
             }
           })
         });
@@ -84,26 +84,26 @@ getData(someParameter, function(err: Error | null, resultA: ResultA) {
 ```
 </details>
 
-### Blog Quote: "We have a problem with promises"
+### ブログ引用: "We have a problem with promises" (promises には問題がある)
 
- From the blog pouchdb.com
+ブログ pouchdb.com より
 
- > ……And in fact, callbacks do something even more sinister: they deprive us of the stack, which is something we usually take for granted in programming languages. Writing code without a stack is a lot like driving a car without a brake pedal: you don’t realize how badly you need it until you reach for it and it’s not there. The whole point of promises is to give us back the language fundamentals we lost when we went async: return, throw, and the stack. But you have to know how to use promises correctly in order to take advantage of them.
+ > ……そして実際、コールバックはさらに厄介なことをします: 私たちがプログラミング言語において存在して当たり前だと思っているスタックを奪うのです。スタックの無いプログラミングは、まるでブレーキの無い車を運転するようなものです: それがどれくらいあなたにとって必要なものなのか、無くなってみないとわからないでしょう。promises の大事なポイントは、私たちが非同期に足を踏み入れたときに失った言語の基本要素、return、throw、そしてスタックを私たちの元へ返してくれることです。ただし、それらの恩恵を受けるためにも、promises を正しく使う方法を知っておかなければなりません。
 
-### Blog Quote: "The promises method is much more compact"
+### ブログ引用: "The promises method is much more compact" (promises メソッドはよりコンパクトだ)
 
- From the blog gosquared.com
+ブログ gosquared.com より
 
- > ………The promises method is much more compact, clearer and quicker to write. If an error or exception occurs within any of the ops it is handled by the single .catch() handler. Having this single place to handle all errors means you don’t need to write error checking for each stage of the work.
+ > ………その promises メソッドはよりいっそうコンパクトで、明快で、素早く書けます。いかなるオペレーションの中でエラーや例外が起こったとしても、一つの .catch() ハンドラで扱うことができます。すべてのエラーを処理するために単一の場所を持つことは、各処理の段階でいちいちエラーチェックを行うコードを書く必要がないことを意味します。
 
-### Blog Quote: "Promises are native ES6, can be used with generators"
+### ブログ引用: "Promises are native ES6, can be used with generators" (promises はネイティブ ES6 であり、ジェネレーターと一緒に利用できる)
 
- From the blog StrongLoop
+ブログ StrongLoop より
 
- > ….Callbacks have a lousy error-handling story. Promises are better. Marry the built-in error handling in Express with promises and significantly lower the chances of an uncaught exception. Promises are native ES6, can be used with generators, and ES7 proposals like async/await through compilers like Babel
+ > ….コールバックはお粗末なエラーハンドリングの層を持っています。プロミスの方が優れています。promises を用いた Express のビルトインエラーハンドリングと結びつき、捕捉されない例外の可能性を大きく下げて下さい。Promises はネイティブ ES6であり generators とともに活用でき、そしてバベルのようなコンパイラを通して async/await のような ES7 での提案となっています。
 
-### Blog Quote: "All those regular flow control constructs you are used to are completely broken"
+### ブログ引用: "All those regular flow control constructs you are used to are completely broken" (あなたが慣れ親しんでいる全ての通常のフロー制御構造は、完全に崩壊しています)
 
-From the blog Benno’s
+ブログ Benno’s より
 
- > ……One of the best things about asynchronous, callback-based programming is that basically all those regular flow control constructs you are used to are completely broken. However, the one I find most broken is the handling of exceptions. Javascript provides a fairly familiar try…catch construct for dealing with exceptions. The problem with exceptions is that they provide a great way of short-cutting errors up a call stack, but end up being completely useless if the error happens on a different stack…
+ > ……非同期なコールバックベースのプログラミングについていえる最高のことのひとつは、基本的にあなたが慣れ親しんでいる全ての通常のフロー制御構造は、完全に崩壊しているということです。しかし、私が最も崩壊していると思った点は、例外の処理です。例外に対処するために、JavaScript はかなり一般的になった try...catch 構造を提供しています。例外の問題は、それらはコールスタック上でエラーをショートカットする素晴らしい方法を提供する一方で、異なるスタックでエラーが起こったときに全く役に立たずに終わるということです...