6

ほとんどの場合、チェックされていないものであっても、Java で例外をキャッチすることができます。ただし、それについて何かを行うことが必ずしも可能であるとは限りません (たとえば、メモリ不足)。

他のケースでは、私が解決しようとしている問題は設計原則の問題です。私は、たとえそれが間に合うように検出されたとしても、例外的な状況をいつあきらめるべきかを示す設計原則または一連のルールを設定しようとしています。目的は、アプリケーションをできるだけクラッシュさせないようにすることです。

誰かがすでにブレインストーミングを行い、これについて話し合っていますか? 特定の一般的なケースと考えられる解決策、または経験則を探しています。

アップデート

これまでの提案:

  • データの一貫性が損なわれる可能性がある場合は、実行を停止します
  • データを削除できる場合は実行を停止します
  • 何もできない場合は実行を停止してください (メモリ不足...)

  • 主要なサービスが利用できない場合、または利用できなくなり、再起動できない場合は、実行を停止します

  • メソッド/サービスは、安定した状態からその義務を実行できるかどうかを確認する必要があります。そうでない場合は、ユーザーに通知 (ログ) して何もしない必要があります。

  • アプリケーションを停止する必要がある場合は、できるだけ適切に機能を低下させます
  • db トランザクションでロールバックを使用する
  • カスタマイズされた例外を使用して、ハンドラーによって状況を解決する方法に関するヒントを提供できます
  • できるだけ多くの関連情報を記録する
  • 開発者に通知する

  • 状態とデータの一貫性をできる限り維持する

  • クイックフィックスは有害な場合があります。デバッグ時に、アプリケーションをクラッシュさせ、原因を詳細に分析することをお勧めします

4

3 に答える 3

2

Java と .Net の作成者は、スローされた例外オブジェクトの TYPE を使用して、それをいつキャッチし、いつ解決したと見なすかを決定することを決定しました。これはおそらく、C++ が例外を処理する方法によって動機付けられた設計上の決定です。C++ の例外処理は多くの点で以前のものよりも改善されていましたが、キャッチされた例外を判断するための主要な手段として例外オブジェクトの型を使用することは、優れた機能の 1 つではありませんでした。

例外のキャッチは例外の種類によって制御されるため、失敗した操作がシステム内のオブジェクトの状態を変更したかどうか、または失敗の原因がオブジェクトが破損した状態にあることによるものかどうかを例外が示す標準的な手段はありません。呼び出し元にとって予期せず、渡されたパラメーターと互換性がない場合でも、呼び出されたメソッドによって完全に正当であると見なされる状態)。多くの場合、ユーザーの要求に応じて、システムが何かを実行しようとして実行できないメソッドを呼び出した場合、そのメソッドはオブジェクトの状態に悪影響を与えることはなく、問題の原因はオブジェクトが状態が破損している場合、多くの場合、要求されたアクションを実行できなかったことをユーザーに通知して続行するのが最善の方法です。不運にも、上記のタイプの「無害な」例外と、システム全体に深刻な問題があることを示す例外とを区別する方法はありません。例外の 99% はおそらく比較的無害ですが、ドキュメントを開く際に破損を引き起こす可能性のある条件が原因で発生する例外はわずかです。開いているドキュメントが破損している場合、ディスク上の正常なコピーを破損したものに置き換えるよりも、プログラムが即座に完全にクラッシュする方がよい場合があります。

カスタム例外をスローする場合、例外の種類にプロパティを含めることができる場合があります。これにより、例外に対して何をすべきかをコードでより適切に決定できるようになります。残念ながら、無害かどうかにかかわらず、スローされる多くの例外には、そのようなプロパティは含まれません。

于 2012-07-03T18:50:10.503 に答える
1

アプリケーションのクラッシュは、アプリケーションのクリティカルレベルとデプロイメントアーキテクチャに依存するものです。

たとえば、地球からロケットを制御している場合、アプリケーションはクラッシュしないはずです（制御できない状況とデータの優先順位を除く）。

アプリケーションを設計するときは、データストア内のデータが削除または変更されないようにアプリケーションを設計する必要があります。

結論として、アプリケーションがクラッシュしたときにルールを設定するためのハードで迅速な方法はありません。

于 2012-07-04T03:12:29.613 に答える
1

アプリケーションをクラッシュさせる理由とタイミングに特定のルールはありません......次の理由でアプリケーションをクラッシュさせます。

1.応急処置はキックバックする可能性があり、リスクを伴う可能性があります。コードクラッシュの実際の理由が何であるかを知らずに、バグを修正するのが適切だとは思いません。アプリケーションをクラッシュさせると、コードの間違いにつながります。

2.コードをクラッシュさせると、プログラミング言語と論理エラーをよりよく理解するのに役立ちます。

それがアプリをクラッシュさせる私の理由です..

于 2012-07-03T16:29:38.450 に答える