凄腕エンジニアさんから学んだ例外の話 - Qiita

はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました！という声をいただけたので、アウトプットしていきたいと思います。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth

[daishi_n]

入力チェックエラーと異常を示す例外は分けるよね。ロジックで弾けるものは普通に準正常処理として例外は発生させず、それで弾けないものだけ例外処理にしてる

[sumomo-kun]

Result型のようなののほうがハンドリングしやすいけどな

[gsggyhig]

例が悪い。例外発生処理はコスト高いからバリデーションチェックして返すのがいい

[Filone]

すでに散々言われてるがthrow-catchの乱用はGOTOみたいなものだし、大抵の言語では例外処理は高コスト。例外は文字通り例外の場合に使われるべきであって、想定できる失敗なら失敗という結果を返したほうがよい。

[n314]

自分なら入力不備も申請済みも例外にしないかな。もしこの異常をビジネスロジック層でも考慮するなら例外だけど、その場合はcatchせずにサーバーエラーにする。入力チェックプログラムのバグという扱い。

[karikari1255]

言わんとしてることは分かるが既出だが例が悪いね。外部API連携とかが独自例外の活躍どころじゃないか。例外内容を分けることで握り潰していいかどうかのヒントも作りやすい

[ene0kcal]

例外の扱い大事。いまのPJ、マイグレーションの残骸やVB6の負債やらでぐちゃってます。例外も例外ではない。あとこれとは別にログの設計大事。ログを制するものは全てを制すとも言えなくはないと思ってるので。

[rryu]

必ずキャッチしないといけないようなものを例外にしても誰も嬉しくないという。例外にしたくなるのは戻り値の表現力が弱いだけなので処理結果を表す型を作れば良い。

[circled]

「例外発生処理はコスト高いからバリデーションチェックして返すのがいい」→ これよな。バリデーション通った値だけDBで受けることで、already submittedみたいなのも存在しないパラメータのデータ放り込み攻撃も防げるし

[fukken]

ロジック上想定できるものは例外として扱わない方が設計としては望ましい（本当の「例外」処理もシンプルになる）。いわゆるResult型を使う方がいい習慣。

[retdaisuke]

例外、最初の設計方針が肝心だし、悩みだすとほんと難しいよね [あとで読む]

[pmint]

例外は例外を表すもの。プロダクトを完璧にテストしたあとに残る「何にでも例外はある」って不安の「例外」。大昔からある、例外に利用価値を見いだしてるアンチパターン。あと「詳しい説明は脆弱性」は無い。

[Wafer]

凄腕（笑）ＩＴエンジニア？本当にエンジニアかどうか怪しいもんだ

[tekmak]

エンジニアさんと相互に最善を尽くそうとしてるところが良いと思います

[queeuq]

プレゼンテーションレイヤーで検査する前提で、ドメインに流入した場合ドメインでは例外が発生する設計にするってことでは？/具体的な例外クラスを作らないってとこからも大前提で非検査例外でしょこれ。

[BOOOOOOOON]

最近のFrameworkは非検査例外を使って処理することを推奨してるよ。Spring Boot使ってRESTful API開発してる場合ならそれに従っとくのがいい

[devrabi]

言語やレイヤによっても変わる話だと思います

[opnihc]

バリデーションにチェックの意味が入ってるのでバリデーションチェックという言葉見ると痒くなる

[dekasasaki]

Tさんと聞くとどうしても寺生まれのTさんを期待してしまい、いつ例外を「破ぁ！！」してくれるか心待ちにしてしまったのだが、寺生まれのTさんだと扱ってくれるのは例外じゃなくて霊害ですね

[j1nsuke]

例外処理は奥深い

[iww]

例外はほっといて落ちるに任せる、というのも立派な例外処理

[tor4kichi]

.Netの推奨事項的にも合ってるっぽい＜"呼び出しコードではリターン コードを確認しないので、例外によって、エラーを見過ごさないようにします。" https://learn.microsoft.com/ja-jp/dotnet/standard/exceptions/best-practices-for-exceptions

[GENS]

他の人も書いてるけどtry-catchはたいていの言語でパフォーマンス悪くなるから、わかりきってるところでまで使うべきではない。

[turanukimaru]

私は例外めっちゃ投げる。むしろメッセージに情報が足りない。'already submitted' + user ID:xxxxx, submitted at 日付, 安全な内容、許される操作、まで出す。そのほうが結合テスト時にバグの位置や壊れたデータを見つけやすい。

[unhappychoice_e]

独自エラークラスは絶対作るべきで、エラー時の詳細情報詰めこめたり、コード上に既知のエラーが明示されるメリットが大きい。TypeScript なら Promise が実質的に Result なので Promise.reject と同等のasync 中の throw は普通に書く

[PrivateIntMain]

"補足：メンテナンス前提の例外"に書いてあることが重要か。あくまで何でそんな事になってるのと調査を促すためのトリガーでしか無い。

[hatest]

言語によるから、一律この考えで進めるとだめでは

[new3]

例が悪いがチェックすり抜けを考えてInvalidInputExceptionを作るケースはある。凄腕エンジニアTさんのn=1の意見も良いけどこの辺の意見(とリンク元)一通り読む方がタメになると思う<https://softwareengineering.stackexchange.com/a/403341>

[tettekete37564]

“期待する挙動以外は全て例外で良くて〜〜” < それ挙動を読めてない初心者の理論じゃん。アサーションとカバレッジとテストで無くせるだろ。自分がコードを書くレイヤーで対処できないエラーだけを例外にしなさい

[sa-yama321]

catch使うのは、バッドパターンなんだってば。凄腕でこのレベルってのが泣けるわけで。この記事の知識を全て身につけた上で独自例外とかcatchとかは使わない、って方向に考えられるようではないと、いかんだろと。

[kako-jun]

自分では例外をthrowしない。言語によっては何でも例外が良いと思われてた思想があって、組み込み関数は例外するので、最小スコープでcatchして戻り値に丸める。戻り値はどの言語でも、多値を返すように統一してる

[dagama]

業務エラーも全部例外で処理するというポリシーが決まってればそれはそれで呼び出し側も作りやすいので悪くはない　今どき例外飛ばされてコード読むのに困るような環境で開発してるやつが悪い

[cu39]

想定内の誤入力、想定外の誤入力、発生コスト、みたいな話もわかるし、try/catchブロックはよほど注意を要するとこだけに絞りたいというのもある。実際は境界ケースもあって迷うことも多い。

[ryousanngata]

みんななんでそんなに怒ってるの？例外をカジュアルに扱える言語（Java,Python,Rubyあたり）での話なら良い記事だと思うけどな

[tiamointer]

“tchして、ログを残す、Slackに通知する、Sentryに通知するということをしてしまっている場合、例外が起こった時の挙動をドメイン層で決めてしまっています。 Webやバッチという文脈によってログを残す残さないを変えたり

[kagehiens]

正常系から書き始めるのはいいけど、それを最後まで書き切らずに途中からは異常系を合わせて書くようにすることを強く勧めたい。正常系だけ最後まで書いてしまうと異常系だけ書き足す事には気持ちのブレーキが掛かる