私がthrowを使わない理由

この記事について JavaScriptではthrow文という文を使うことで例外を投げることができます。 このthrow文ですが、私はレビューなどで例外を投げないでくださいというコメントをするのですがその理由とどのようにコードを変更すればよいのか、ということを書いておこうと思いました。 前提条件 この記事の内容は下記の条件を前提として書き進めていきます。 TypeScriptを採用していること フロントエンド開発の場合 Node.jsを利用したサーバーサイドのコードやCLIツールの開発、各種ライブラリの開発については本記事の対象に含まれないことをご了承下さい。 結論 先に結論から書いておくとTypeScriptを利用している場合例外はカスタムエラーを返却するか、Result型を利用するのがよいと思っています。 次の章からサンプルコードを用いながらthrow文を使った実例と、代替え案について記

[gfx]

JavaScript/TypeScriptでthrowをあまり使わないというのは同意するけど、全く使うべきでないとも思わなくて「catchしない前提」、つまりRustやGoでいうところのpanic的な意味で使うのがいいと思ってる。

[hase0510]

RustのResult<T, E>が欲しいという人は各所におり、他の言語でもそれっぽいライブラリが見つかったりする／楽な記法ができるユーティリティが整備されてるかが重要で、この記事みたいにreturnだけで4行も書くのは嫌だよね

[twotiger]

このさコードレビューで突然「このthrow文ですが、私はレビューなどで例外を投げないでくださいというコメントをする」とか言い出すのレスバトル勃発だよ。それレビューじゃなくてプロジェクトの立ち上げに決めといて

[mole-studio]

status4xxでthrowしてくる仕様にはいつまでも納得がいかない

[baronhorse]

色々な言語が通った道だと思うけど標準ライブラリやサードパーティライブラリが投げてくる以上後付けのResultやらEitherは問題をややこしくするだけだと思ってる

[canadie]

Typescript 使わないけどパッと見バッドノウハウだよなあ。逆に呼び出し側で処理しきれない例外は呼び出し側がまたreturn Error()してさらにその呼び出し側が…って循環が生じるわけでしょ。単一責任の法則に反しているかと

[umai_bow]

ライブラリやブラウザAPIがthrowするし、Promiseもrejectするし、アプリケーションレベルで徹底したところで別に……と思ってしまう……。

[door-s-dev]

throwsとかないもんね。とはいえ呼び出し階層深くなった場合のエラーハンドリングで使いたいこともありそうだし設計次第かな

[IzumiSy]

Elmがこの思想なので理想としては同意だけど、これをTypeScriptでやりはじめるとlintルールとかでガチガチにしないといけなかったりするのが微妙。

[trace22]

JSDoc 使うだけだけど値で型を見分けてくれるおかげで安心感はあるかな。環境の都合で例外使わないのだけど、大体のエラーは何もできないので大域脱出したほうが見通しよくなるだろうなと思う。

[dorapon2000]

“このように例外を投げるのではなく、エラーを返却することにより利用側ではError型が含まれるため失敗する可能性のある関数であることが分かります。”

[z67kjh]

「レビューなどで例外を投げないでくださいというコメントをする」というのはプロジェクトで決めてるけどLinterにルールがなかったりするからじゃないかな。コミットフックでいくらでも対策できるとは思うけど…

[ka-ka_xyz]

typescriptの最大の弱点が例外周りだと思ってる。throwsで「明示的にスローされる可能性のある型」が定義出来ないのつらいし、非同期処理との相性も悪い(握りつぶされる)。Result型も外部packageを呼ぶときの面倒さがあり。

[fuji_haruka]

わかるしそうしたいが、標準ライブラリがそうなっていないのとResultモナドのインターフェイスを持つライブラリに依存しなきゃならなくなるので、決断には勇気がいる

[dev0000_1]

対象外だが、サーバー側が catch を前提にしていることが多くて、それに歩調を合わせるのが多いのかしら。

[fukken]

開発時に想定できるようなもの（ネットワークリクエストの失敗とか）は「例外」ではない、みたいな設計手法論は例外を多用する言語（Javaとか）では結構見る。

[atsushieno]

JSはthrowを無理に使わないようにする言語じゃないと思うけど、使用分野によるのかもねえ。普遍的には受容できない考え方だ。

[turanukimaru]

JS/TypeScript だと他の人が catch してくれることが期待できないのと async await と相性が悪いというか非同期で他の人が正しくcatchしてくれることがまったく期待できないので失敗時のデータをなんとかこねくりだして返してる。

[queeuq]

非検査例外ならthrowすればいいし検査例外についてはResultかな。

[tattyu]

returnで返すの型が緩い言語でしか出来ないトリックだな。例外投げるかどうか毎回チェックするのダルいし真面目に細かくtry/catchし始めるとめちゃくちゃ見通しが悪くなるの言語側でなんとかして欲しい。