その例外、いつキャッチするの？

はじめに 最近、若手のコードレビューをしていて例外の使い方を教える機会があったので、ブログの方にもまとめたいと思います。今回はバッチ編。オンラインだとまた少し違う観点があると思います。また、言語はJavaを前提していますが考え方は例外機構をもつ言語ならあまり変わりません。 TL;DR 例外は原則キャッチしない。バッチは速やかに殺せ 個別箇所でログを出さずに必要な業務情報はExceptionを入れ子にして乗せる 長いバッチのためにはスキップもやむなし 原則、例外はキャッチしない JavaにはErrorとExceptionが存在し、OutOfMemoryErrorとかプログラム上ではどうしようもないものがエラー、ファイルが存在しない(FileNotFoundException)とかプログラム側でハンドリングするもの、と教科書では習うと思います。なのでException系はキャッチするものと、と

[door-s-dev]

キャッチするなじゃなくて握りつぶすな、なら同意。キャッチして投げ直す例挙げてるし

[vegnpomn]

Javaが持ち込んだ、例外なのに予めどういうことが起きるかわかっているという謎の存在の検査例外は本当悪手だったと思う。これがなければ例外を握り潰して続行するっていう発想自体が生まれなかったんじゃないか

[gowithyou]

FileNotFoundExceptionは検査例外だからcatchしないと、呼び出している全てのメソッドの階層でthrows句を記述しなければならない。catchしたくないなら大元のメソッドでcatchして非検査例外UncheckedIOExceptionにラップしてthrowが正解

[hase0510]

そもそも例外という機能がいらないよね、ってのが最近の流れだよなあ。スタックトレースを吐いて死ぬ機能だけあればいい。

[sysjojo]

プログラム中の拾い方だけじゃなくて、運用上の拾い方も基本的な考え方あったほうがいいと最近思う。画面に出ててもわからんので、ログに落として監視ツールで見るなり、監視の仕組みにWebAPIやMQTTで投げたり。

[Kenju]

うーん、なるほど。／キャッチしないとロールバックできない気がするけど、どうなのかな。ジョブに入る前にトランザクションを開始して終わってからコミットすればいい？

[secseek]

大抵はなんかフレームワークを使ってるはずで、フレームワークには例外処理の機能があるはずだからそれに任せるべきですよね

[iww]

例外はキャッチしないのが基本だろと思って読んだら最初からそう書いてあって良かった

[rryu]

結局、例外をキャッチして何事もなく処理を続行するなんてことはほぼないというか、それをやるなら例外でなくていいという。Javaのチェック例外は完全に負の遺産だと思う。

[lainof]

↓例外があるのはJavaがデスクトップアプリとかも考慮しているからでは？例外が発生する状況でデスクトップアプリが落ちてたら使い物にならないし、適切なエラーダイアログを出すために検査例外だと考慮漏れが減る

[tmatsuu]

現場の知見だ。わいわい

[sametashark]

日毎に1440ファイル回す真ん中でバッチに落ちられると困る。そのファイル飛ばして走り切って欲しい

[perl-o-pal]

監視する立場だと、スタックトレースをオペレータに見せても対応は無理だから、メジャーなケースでは適切なエラー吐いてほしいよなとは思う。

[sa-yama321]

大域脱出で、Goto文と一緒だから、使うべきじゃないんだって、例外使うコードは信頼性がダダ下がりだから。例外が出たらその場で落としてOK。そしてその場で落ちるようなプログラムにならないように作るのだよ。

[gabari]

catchするのはビジネスロジックだけ、っていうのがシンプル。アプリとかライブラリなら、変なデータがある、とかも自作のビジネス例外にしてから投げ直すかなぁ、デスクトップは落ちなくなるまでテストして修正。

[kmaebashi]

最近は検査例外が嫌いな人が多いようだけど、検査例外が不要なら全メソッドにthrows Exceptionと書いとけば済む話で、機能としては必要だと思う。後の言語で排除されたのは怠惰なプログラマに迎合しただけでしょ

[umai_bow]

突き詰めると go の panic やんなあ

[ka-ka_xyz]

"バッチは問題があったら速やかに殺す"はモノによるというか「csvのN行目にある参照IDはシステム上存在してない」みたいな場合の例外だと、その行の処理は終わらせて次の行へ進むのが最適解で。

[cbkf]

.NETだとException.Dataに情報載せられるのでcatchしてエラー情報足して throw; (スタックトレース壊れない) はある。あと個人的に例外といえばこの記事 http://web.archive.org/web/20190516163737/https://blogs.msdn.microsoft.com/nakama/2009/01/08/netjava/

[vcc]

例外は原則キャッチしない。バッチは速やかに殺す。Javaのスタックトレースは、例外をキャッチしないだけで失敗したファイル名や何行目でエラーが発生したかも確認できます。

[Kirche]

約20年経っても「例外をめぐる議論 (http://bit.ly/3sckjSb )」してるのである

[mayumayu_nimolove]

キャッキャうふふ

[Flume]

ちょっと気になったんだが、この例のケースはまあこれでも良いとして、try-with-resources使えないクラスだとこの書き方無理では？

[jintrick]

スタックトレースを握りつぶすな案件

[strawberryhunter]

例外が要らないとまで言っている人と星を付けている人は、Rustでも使っておけばいい。検査例外はIDEが教えてくれるので私は楽で良いと思う。本当はプログラムの境界でcatchが強制される程度がちょうど良い。

[turanukimaru]

例えば外部サーバのAPIにアクセスして失敗した時は、どのサーバにどんなリクエストを送ってレスポンスも記録しないと苦しむ。バッチも失敗をはじいて成功レコードは通す運用もある。使えないなら使うなはまぁそうだね

[tonocchokun]

キャッチしたときに何をすればいいか明確なクラスがキャッチするのか良いという話なんだろうな。変にファイルの内容を読むクラスがIOExceptionキャッチされるとなんでだよ！ってなることもあるから難しいよね

[Lagenaria]

バッチは速やかに落とす、っていうのは後続処理へ進んでしまうと二次障害を容易に引き起こしてしまうからかな。想定外のエラーの場合は特に

[yarumato]

“JavaにはErrorとExceptionが存在するが、Exception系はキャッチするもの、と思っている人もいる。実サービスにおいてバッチの開発/運用ではキャッチしない。”

[tacamula]

“例外は原則キャッチしない” ちゃんとエラー扱えないレベル向けとしてはわかる。レイヤーごとに抽象化したい気持ちもあるが、現実的にペース維持しつつ徹底させきれるかという問題もある

[mushus]

エラー処理設計をしっかりして適切に実装しろっていう話かと思われる。今回の場合、エラーの設計要件がスタックトレースを出せっていうコンテキストがあると思われる。

[harumomo2006]

某国のシステムを作ってた時画面上にエラーは出してはいけないというルールだったのでメインルーチンでキャッチしながらどんなエラーが発生してもこれは正常ですみたいなメッセージを出しつつシステムを終了させてた

[shodai]

“まず最初のコードの最大の問題はスタックトレースが出ないことです。”

[nakag0711]

例外はunix的な上手くいかなかったら異常終了という考えとは相性いいね。逆に個別にエラー処理書きたいときはむしろ面倒なので、例外は抑制的に投げるのがよさそう

[unmarshal]

GO言語で言えばerrorはちゃんとハンドリングして、想定していないものは遠慮なくpanicにすることだと思っている。（パッケージ開発は除く）

[azmin]

調査の起点になるようなメタデータはBugsnagへのリクエストに乗せるようにしてから、だいぶ捗るようになった

[tettekete37564]

キャッチしなくて良いってのはモノによるのでは？メモリ上のデータがいつ失われても良いとか、ファイルが壊れたりデータ不整合を起こしても良いとか、色々条件があると思うよ

[yuno001]

今じゃなかった。