※当サイトの記事には、広告・プロモーションが含まれます。

Javaの独自例外のベストプラクティスが知りたかったんだが...

www.itmedia.co.jp

 出沢氏は情報流出問題への対応として、システムの構築などさまざまな面で依存していた韓国IT大手NAVERへの委託関係を終了させることをあらためて表明。セキュリティやガバナンス(企業統治)強化へ向けた議論を行う社長直轄の委員会を設置したことなども説明した。

「責任取る時期では」LINEヤフー株主総会で厳しい声相次ぐ 情報流出問題対応は長期化 - ITmedia NEWS

 情報流出は2023年、LINEヤフーと一部のシステムを共通化していたNAVER傘下企業がサイバー攻撃を受けたことで発生。総務省はLINEヤフーがNAVERから一定の資本支配を受ける関係を含めた経営体制の見直しを求め、4月までに2度の行政指導を行った。

「責任取る時期では」LINEヤフー株主総会で厳しい声相次ぐ 情報流出問題対応は長期化 - ITmedia NEWS

⇧ 記事を見た限りだと、情報流出はサイバー攻撃起因ってことであるならば、まずは、セキュリティ部分を内製化すれば良いような気がするんだが...

Javaの独自例外のベストプラクティスが知りたかったんだが...

Javaの標準APIや、ライブラリ、フレームワークなどで用意されている例外クラスだけだと足りないってなった場合に、

docs.oracle.com

Creating Exception Classes

When faced with choosing the type of exception to throw, you can either use one written by someone else — the Java platform provides a lot of exception classes you can use — or you can write one of your own. You should write your own exception classes if you answer yes to any of the following questions; otherwise, you can probably use someone else's.

  • Do you need an exception type that isn't represented by those in the Java platform?
  • Would it help users if they could differentiate your exceptions from those thrown by classes written by other vendors?
  • Does your code throw more than one related exception?
  • If you use someone else's exceptions, will users have access to those exceptions? A similar question is, should your package be independent and self-contained?

Creating Exception Classes (The Java™ Tutorials > Essential Java Classes > Exceptions)

Oracleの公開しているチュートリアルの情報によると、

『「独自例外」を作ることもできるよ』

とのことなのですが、ベストプラクティス的、乃至は、アンチパターン的な内容について言及してくれている情報が無いと...

で、海外でも、

www.quora.com

⇧「独自例外」を作るべき時ってのが分からんのだが?って情報が出回ってるぐらい、独自例外についてのプラクティスは確立されていないらしい...

Javaは、枯れた技術になってきたはずなのに、開発に必要そうな情報が発信されていないのは何なんでしょうね...

一応、

www.oracle.com

Oracleが、2007年に公開している情報で、『Why Exceptions Matter』と謳っているぐらいなので、例外は重要なんだと思うんだけど、その割には、Google検索で上位表示されないんよな...

ちなみに、Oracleの公式っぽいBlog記事で、

ところで、Javaでは、非チェック例外をスローすることについて、何の制約も課していません。つまり、非チェック例外は、メソッドがその非チェック例外をスローする可能性があるかないかにかかわらず、また、非チェック例外のスローが可能であるかないかにかかわらず、宣言しても宣言しなくても構いません。

https://blogs.oracle.com/otnjp/post/quiz-yourself-custom-exceptions-advanced-ja

対照的に、メソッドがコール元にチェック例外をスローできるのは、throws句でその可能性を宣言している場合に限られます。メソッドのthrows句では、スローされる可能性がある実際の例外の親を宣言するだけで十分です。子の例外は親の例外型のインスタンスであるからです。

https://blogs.oracle.com/otnjp/post/quiz-yourself-custom-exceptions-advanced-ja

⇧ とのことらしい。

www.oracle.com

⇧ 上図のように、Javaの例外は、

  1. 非チェック例外(非検査例外)
    • Error
    • RuntimeException
  2. チェック例外(検査例外)
    • Exception

に大きく分かれて、Exception を継承する独自例外クラスを定義したとして、メソッド内で独自例外をthrowしている場合は、メソッドの実装でthrows句 を付けておかないと、呼び出し元に例外を投げることができないらしい。

digital-literacy88.com

⇧ 上記サイト様みたいなメソッドの実装にする必要があると。

とりあえず、

xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com

⇧ 上記サイト様によりますと、

  1. 技術的例外
  2. ビジネス例外(業務例外)

を明確に分けるべき、という思想らしいのだけど、

  1. 非チェック例外(非検査例外)
    • Error
    • RuntimeException
  2. チェック例外(検査例外)
    • Exception

上記のどのクラスを継承して独自例外を作れば良いかの指針について言及してくれていない...

shuji-w6e.hatenadiary.org

ビジネス例外は適切に処理をしなければなりません。したがって、Javaの場合はcatchまたはthrowsを強制する非実行時例外とするべきでしょう。すべてを実行時例外としてしまい可読性を高める選択肢もありますが、ハンドリングを忘れるリスクがあるので注意すべきです*1

*1:少なくともテストを行わない現場やスキルレベルの低いメンバーがいる中で工数削減の為に行うべきではない

21-技術的例外とビジネス例外を明確に区別する - やさしいデスマーチ

⇧ 上記サイト様によりますと、ビジネス例外(業務例外)については、「チェック例外(検査例外)」にするのが一般的ではありそう。

う~む、Javaって肝心な部分が曖昧になっていて辛いですな...

情報が錯綜しているから、「守破離」的なアプローチが成立しにくいんよな...

毎度モヤモヤ感が半端ない…

今回はこのへんで。