[フレーム]
はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

気に入った記事をブックマーク

  • 気に入った記事を保存できます
    保存した記事の一覧は、はてなブックマークで確認・編集ができます
  • 記事を読んだ感想やメモを書き残せます
  • 非公開でブックマークすることもできます
適切な情報に変更

エントリーの編集

loading...

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

タイトルガイドライン

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます
コメントを非表示にできます コメント表示の設定

ブックマークしました

ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

292users がブックマーク コメント 48

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

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

292 users zenn.dev/koduki

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

はてなブックマーク

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページ

記事へのコメント48

  • 注目コメント
  • 新着コメント
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
監視する立場だと、スタックトレースをオペレータに見せても対応は無理だから、メジャーなケースでは適切なエラー吐いてほしいよなとは思う。

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

2023年11月04日 リンク

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

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

2023年11月04日 リンク

その他
yuno001
今じゃなかった。

その他

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー
アプリのスクリーンショット
いまの話題をアプリでチェック!
  • バナー広告なし
  • ミュート機能あり
  • ダークモード搭載
アプリをダウンロード

関連記事

usersに達しました!

さんが1番目にブックマークした記事「その例外、いつキ...」が注目されています。

気持ちをシェアしよう

ツイートする

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

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

ブックマークしたユーザー

  • techtech05212024年06月20日 techtech0521
  • maasayan2024年01月07日 maasayan
  • kkeisuke2023年11月19日 kkeisuke
  • tomato37132023年11月19日 tomato3713
  • fumikony2023年11月19日 fumikony
  • tmatsuu2023年11月19日 tmatsuu
  • Toge2023年11月13日 Toge
  • fuyu772023年11月09日 fuyu77
  • usako11242023年11月07日 usako1124
  • lugecy2023年11月07日 lugecy
  • fumiyas2023年11月06日 fumiyas
  • field_combat2023年11月06日 field_combat
  • k_wizard2023年11月06日 k_wizard
  • hm_hs2023年11月05日 hm_hs
  • sametashark2023年11月05日 sametashark
  • perl-o-pal2023年11月05日 perl-o-pal
  • modoroso2023年11月05日 modoroso
  • dhesusan46492023年11月05日 dhesusan4649
すべてのユーザーの
詳細を表示します

ブックマークしたすべてのユーザー

同じサイトの新着

同じサイトの新着をもっと読む

いま人気の記事

いま人気の記事をもっと読む

いま人気の記事 - テクノロジー

いま人気の記事 - テクノロジーをもっと読む

新着記事 - テクノロジー

新着記事 - テクノロジーをもっと読む

同時期にブックマークされた記事

いま人気の記事 - 企業メディア

企業メディアをもっと読む

はてなブックマーク

公式Twitter

はてなのサービス

Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しましたx

AltStyle によって変換されたページ (->オリジナル) /