例外機構
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にしたりするが、それは、そのような関数があったときだけ有効なだけであって、そうでないケースのほうが多いので、そこまで嬉しくないmrsekut.icon
可読性もあまり良くない
throwしているコードを見つけても、それがどこでcatchされるかは処理を追っていかないと理解できない
いや、行き先が指定されていない分gotoより質が悪いかもしれないmrsekut.icon
try..catchを書く際のコツ
try節をできるだけ小さくする
code:ts
// func1,2,3のどれでthrowされたのかパッと見で判断できない
try {
func1();
func2();
func3();
} catch (e) { .. }
func1とfunc2の中で同じ種類の例外(ex. TypeError)が発生すると、catchに来たときに条件分岐したとしても、どちらから来たのかが判断できない
敢えてこうするケースもあるとは思うmrsekut.icon
「try」「catch」は使いたくなかったMatz.icon
代わりに「rescue」「ensure」を使った
memo
typescript
(goとは異なり)エラーハンドリング処理を集約できるのが利点？
python
例外により望むものはシステムの用途による
例外の利点
参考