例外機構
try節の中で生じた例外の種類によってcatchの中でそれに対する例外処理を行う
何かの関数を呼んだ場合、その内部の処理に依って、例外が生じる可能性がある
関数の内部で例外が生じると、その関数の処理は中断し、
その関数の呼び出し元に処理が移行し、更にその呼び出し元に処理が移行し、というのを続け、
最も近い
try 節に続く catch 節に処理が移るだから、
try..catch を使うことで、その影響範囲を操作することができる try の中で関数を呼んだ場合、その中で生じた例外は、その try より外には影響を及ぼさないそこで「例外が生じやすい関数」などは
try..catch で囲うことで、その例外をhandlingすることができるでは、自分で書いたプログラム内で一切
try を使っていないとどうなるかその場合は、使用しているフレームワークなり、言語が補足することになる
あるいは、補足されずにプログラムがクラッシュする
それはフレームワークや言語の仕様に依る
try..catch などの例外機構の問題点例外を
throw しうる関数を、名前や型を見ただけで判断できない例えば、JSの
JSON.parse() は try..catch の中で書くべきという了解があるが、使用法のdocsを読む以外に知る術がないつまり、docsが存在しないような関数があった場合に、それを判別できない
TypeScriptでは、「絶対にErrorをthrowする関数」の返り値は
never にしたりするが、それは、そのような関数があったときだけ有効なだけであって、そうでないケースのほうが多いので、そこまで嬉しくない可読性もあまり良くない
throw しているコードを見つけても、それがどこでcatchされるかは処理を追っていかないと理解できない構造的にはgotoと同じ
いや、行き先が指定されていない分gotoより質が悪いかもしれない
try..catch を書く際のコツ try 節をできるだけ小さくするts// func1,2,3のどれでthrowされたのかパッと見で判断できない
try {
func1();
func2();
func3();
} catch (e) { .. } func1 と func2 の中で同じ種類の例外(ex. TypeError)が発生すると、catchに来たときに条件分岐したとしても、どちらから来たのかが判断できない敢えてこうするケースもあるとは思う
>#WIP
Rubyの例外処理の予約語のルーツ
「try」「catch」は使いたくなかった
代わりに「rescue」「ensure」を使った
Eiffelから借りてきた
memo
typescript
(goとは異なり)エラーハンドリング処理を集約できるのが利点？
これのエラーハンドリングの所ちゃんと理解したい
python
例外により望むものはシステムの用途による
例外の利点
参考