私は自分のプログラムを動作させ、すべて完了しました(Java)。就職面接のための短くて簡単なプログラムです。カスタム例外をスローして、不適切な入力形式などを処理します。それが最善の方法ですか、それとも印刷ステートメントを作成するだけですか?
4 に答える
例外は、他のコードによって処理される場合にのみ役立ちます。
再利用可能なライブラリを作成している場合は、必ず例外をスローする必要があります。
コードにエラーを伝えるのではなく、エラーをコンソールに記録するサードパーティ製ライブラリを呼び出すことほどイライラすることはありません。
ただし、スタンドアロンのユーティリティを作成している場合は、見苦しいスタック トレースよりもわかりやすいエラー メッセージを表示する方が適切です。
最も柔軟なアプローチは、例外をスローする再利用可能なコードを記述し、わかりやすいメッセージを出力するcatch
ブロックをmain()
(またはスタンドアロン部分の別の場所に) 追加することです。
- 不適切な形式をインラインで処理する場合、コードは読み取り可能ですか? そうであれば - 結構です、そうでなければ - 例外をスローして別の場所で処理します
- 解析している場所で不適切な形式を適切に処理できますか、またはより一般的なメソッド/クラス/モジュールが実際にルーチンを呼び出しており、何をすべきかを決定する必要がありますか? 後者の場合 -> 例外をスローする
一般的に - それは異なります。この特別な状況を「インライン」で処理できる場合は、処理できます (読み取り可能であることを確認してください)。そうでない場合 - 例外をスローします。
例外のベスト プラクティスに関する参考資料を次に示します。これらに従っていることを確認する必要があります。
あなたの特定のケースでは(あなたが提供した詳細に基づいて)、ユーザーは不適切なデータを含むファイルをアップロード/選択する可能性があります。プログラムは、基本的な Java ランタイムの問題をキャッチし、ユーザーに情報を返すことによって、これを処理する必要があります (「スレッド内の例外」ではなく、ユーザーにとってより読みやすいもの)。これらのアルファベット文字をチェックしている場合は、例外をスローせずに (ユーザーにエラーを表示して) それを処理する必要があります (これが本当に必要な動作でない限り)。
例外は、プログラムが正常に動作しない場合に発生します。
j2se から j2ee に進化すると、例外はより複雑になり、数が増えます。
スタンドアロン アプリケーションの場合
- アプリケーションが非常に単純な計算機である場合、ユーザー入力がフィルター処理され、数少ない例外の 1 つがゼロ除算になるため、例外を完全に忘れてしまう可能性があります。
- アプリケーションがスクリーン キャプチャなどの単純なユーティリティ ツールである場合、ファイルを保存できない場合 (ファイル i/o での例外)、すべてのタスクを終了し、ユーザーにエラー メッセージを表示するだけで済みます。
- 例 2 の高度なプロジェクトの場合、イメージを temp に保存し、問題が修正されたらファイルの保存を実行する必要があります
エンタープライズ規模の分散型アプリケーションの場合 ここではトランザクション (相互に関連する活動) が関与します。ここでは、ユーザーへの簡単なメッセージも時々必要であり、例外を処理する (関連するトランザクションに必要な変更を行う) ことも必要です!
アプリケーションが多くの国に分散されている場合、あるトラクションの例外は別の国の別のサーバーで変更する必要があります。これには、JMS API (アプリケーション内のメッセージ送信) を使用するものをオプションで組み込む必要があります。
JPA (java persistence api) は、例外のイベントでデータベースを暗黙的にロールバックし、相互に関連するトランザクションに対してそうする機能を提供します。ただし、ロールバックはデータベースにのみ影響し、インスタンス変数(オブジェクト値)には影響しません
そして常に、行番号でエラーを示す正確なスタックトレースをユーザーに読み取らせたくない.....