Fix typos

Author: ravelll

exception.rst

@@ -367,11 +367,11 @@ Node.jsで ``async`` / ``await`` やら ``Promise`` を一切使っていない
 例外処理機構以外で例外を扱う
 --------------------------------------
 
-これまでTypeScriptにおける例外処理の方法や作法などを説明してきました。しかし、ベースとなっているJaavScriptの制約により、お世辞にも使いやすい機能とは言えません。理由は以下の3つです。
+これまでTypeScriptにおける例外処理の方法や作法などを説明してきました。しかし、ベースとなっているJavaScriptの制約により、お世辞にも使いやすい機能とは言えません。理由は以下の3つです。
 
 * Javaの ``throws`` のように、メソッドがなげうる例外の種類がわからず、ソースの関数の実態やドキュメント（整備されていれば）を確認する必要がある
-* JavaやC++のように、 ``catch`` 節を複数書いて、型ごとの後処理を書くことができず、 ``insteadof`` を駆使してエラーの種類を見分けるコードを書く必要がある
-* ``Promise`` や　``async`` 関数で、何が ``reejct`` に渡されたり、どんな例外を投げるのかを型定義に書く方法がない
+* JavaやC++のように、 ``catch`` 節を複数書いて、型ごとの後処理を書くことができず、 ``instanceof`` を駆使してエラーの種類を見分けるコードを書く必要がある
+* ``Promise`` や　``async`` 関数で、何が ``reject`` に渡されたり、どんな例外を投げるのかを型定義に書く方法がない
 
 例外に関しては、補完も効かないし、型のチェックも行えません。いっそのこと、例外処理機構を忘れてしまうのも手です。例外処理のないGoでは、関数の返り値の最後がエラーという規約でコードを書きます。
 TypeScriptでも、いくつか方法が考えられます。

typing.rst

@@ -38,7 +38,7 @@ JavaScriptは動的言語の中でも、いろいろ制約がゆるく、無名
 例えば、JSONSchemaを受け取るような引数があったら、JSONSchemaのすべての仕様を満たす型定義を記述するのはかなり時間を要します。
 将来やるにしても、まずはコンパイルだけは通したい、というときに使うと良いでしょう。
 
-ただし、これを使うと、TypeScriptが提供する型チェックの恩恵は受けられません。\ ``any``\ から型情報つきのデータにするためには後述の型ガードや型アサーションで変換しなければなりません。利用する箇所で毎回必要になります。TypeScirptの型情報は伝搬するので、なるべく早めに、データが発生する場所で型情報を付ければ、変換が不要になります。そのため、よっぽどの理由がないかぎりは\ ``any``\ を使わない方がトータルの実装コストは大きく減ります。
+ただし、これを使うと、TypeScriptが提供する型チェックの恩恵は受けられません。\ ``any``\ から型情報つきのデータにするためには後述の型ガードや型アサーションで変換しなければなりません。利用する箇所で毎回必要になります。TypeScriptの型情報は伝搬するので、なるべく早めに、データが発生する場所で型情報を付ければ、変換が不要になります。そのため、よっぽどの理由がないかぎりは\ ``any``\ を使わない方がトータルの実装コストは大きく減ります。
 
 それ以外だと、外部からやってくるデータなどはコンパイル時には型情報がわかりません。標準ライブラリのブラウザのサーバーアクセスAPIの\ ``fetch``\ のレスポンスは\ ``any``\ となっています。そのため、\ ``fetch``\ のレスポンスに関しては何かしらの変換処理が必要になります。