前回ログについて話しましたが、ラオタイが彼に会ったかどうかはわかりません。たくさんのログが印刷されています。本当に例外やエラーの原因となったログを探しに行きました。この問題の根本的な原因は何ですか？これは、システムに標準化された統一例外仕様がないためです。古いアイアンが異常を見つけた後、e.printStackTrace（）によってスタックを直接出力しますが、これは実際には非常に危険です。初期段階で例外の統一された処理がない場合、後の段階で統合して調整することは非常に困難になります。例外は、ビジネスロジックと非常に深く結びついています。調整と統合は非常に困難です。したがって、設計は設計システムの最初に完璧でなければなりません。初期のシステム異常やビジネス異常が標準化されていないと、分散監視の後期でも困難になり、システム異常なのかビジネス異常なのかわからない。開発者と運用および保守担当者に正確に通知できない。警察に電話する方法がわかりません。たとえば、間違ったパスワードが出力された場合、アラームがトリガーされる可能性があります。結果はどうなりますか？特に警報量が大きい。警察に通報しないと問題が発生し、ゲームオーバーになります。それはジレンマですか？それはそれを言うことではありません、またはそれはそれを言うことではありません。
シーンレビュー
- ラオスタイに会ったことがありますか？
それは古典的な要約ですか？とにかくそれは私の鍋ではありません、誰もが成長しています。
何かがうまくいかない場合はどうすればよいですか
実際には、問題を反映しています。ユーザーに問題がある場合、プロンプトが明確である限り、ユーザーは電話カスタマーサービスに報告しません。ユーザーからのフィードバックが必要な場合は、システムの異常な設計が不合理であることを意味します。監視システムが導入されていません。ユーザーはこの問題を認識していますが、システムはまだ認識していません。監視システムが行う必要があるのは、ユーザーからのフィードバックの前に知ることです。例外の定義が素晴らしく強力な場合は、プロンプトが表示されたときに問題がどこにあるかがわかります。多くのシステムは現在、問題を見つけるのに長い時間がかかります。問題を見つけるために。これで、問題が発生した場所を正確に把握し、目標を達成し、迅速に対応し、迅速に把握し、問題に対応し、問題の根本原因を特定し、相手が間違いを犯し、明確な指示を得ることができます。彼はオンラインにされたり、実稼働環境に持ち込まれたりしてはならず、オンラインになる前に消去されるべきです。
システム異常設計の出発点
- 優れた異常情報プロンプト、開発および運用担当者は迅速に見つけることができます
- 外部コール例外に応答するときは、それが内部例外なのか、コール条件が満たされない原因なのかを明確に示すことができる必要があります。
- ユーザーの異常な操作に対応するとき、それはユーザーフレンドリーを促すことができます。
異常分類
内部例外
ユーザーが期待する結果に従って応答を返すことはできません。
- リソース環境が原因です（異常なシステム環境、データベース接続タイムアウト、サードパーティサービス応答タイムアウト）
- サードパーティのサービスエラー応答
サードパーティシステムに転送されており、サードパーティシステムのソフトウェアにバグがあり、結果として
- サードパーティの応答結果が間違っている
規則に従って、1と0が返され、結果は-1になります。
- 不正な外部パラメータ
他の人は自分のシステムを呼び出して、パラメータが間違って渡されたことを明確に伝えます。
- 間違ったコーディングロジック
パラメータを呼び出します。最初は1〜10を渡しましたが、11を渡しました。
- 間違った構成
オンラインコードはテストデータベースにリンクされています
- 異常なビジネスデータ（ビジネスデータの欠落）
コード配信エラー、custIdおよびuserIdは逆に書き込まれます。
ビジネス例外
次のようなユーザー操作エラーが原因です：パスワードが正しくありません。
- ユーザー操作エラー
例外をキャッチします。
- 事業条件を満たしていない
事業を行う際には事前に標準化してください。
###システムはそのような例外を正しくキャッチし、
#### 1をスローします。合法性検証のためのメソッド入力パラメーター
- システムの外部で提供されるインターフェース（呼び出し直後に検証し、検証するためにロジックを通過しないでください）の場合、パラメーター検証を実行する必要があります（必須）
- 検証のために、システム内の外層へのインターフェースを提供します
- パラメータ検証用のツールクラス
- 検証されるパブリックメソッド
- プライベートメソッド（パラメーター検証は推奨されません）
2.第三者の対応結果の合法性の検証
- 3番目の方法の結果を取得した後、同意に従って確認します
3.ビジネス処理の前に、ビジネスの前提条件を確認します
- ビジネス処理の前に、ビジネス条件を確認します（彼女の金額を確認し、このアカウントが公安ゲートによってロックされているかどうかを確認します）
- パフォーマンスコストを考慮します（ID番号が存在するかどうかを確認します）
4.ビジネスが処理された後、処理結果を確認します
- 相手方の口座が到着したか、振込口座が正常に差し引かれているか確認してください
5.異常な可能性のあるコードをキャプチャするためにcatchを試してください
- 処理の再開を試みます
- 直接投げる
- 変換後にスロー
###システムエクスポート統合インターセプト処理
統合インターセプトの目的は、発信例外が制御可能であり、呼び出し元が異常情報を理解できることを確認することです。ここで、出口はシステムの統合外部応答ロジックを指します。一般に、3つのタイプのシナリオに分けることができます。 。
#### 1. Web Response
h5、pcページ
- 内部例外
例外ページに移動します
- ビジネス例外
対応するプロンプトメッセージをフロントエンドに返します
- 不明な例外
識別してみてください。識別できない場合は、異常なコードに変換してください
#### 2. HttpAPIインターフェースの応答
- 内部例外
インターフェイスを使用できないというメッセージを返す
- パラメータエラー
応答は、APIドキュメントの例外リストに基づいて返されます。パラメータが不正であり、パラメータの合法性チェックを強化するためにメソッドを呼び出す必要があることを示します
- ビジネスエラー
慣例に基づかない対応するコードとメッセージを返す
#### 3.RPCサービスインターフェイスの応答
- 内部例外
返品サービス利用不可メッセージ
- パラメータエラー
インターフェイスドキュメントに基づいて応答し、例外スタックを直接返します
- ビジネスエラー
例外スタックを直接返す
CheckedExceptionおよびuncheckedException宣言の原則
-
- パラメータが不正にスローされた場合、返される結果は不正です（つまり、ソフトウェアBUG）uncheckedException
-
- 呼び出し側のプログラマーが意識的にアクションを実行する必要があると思われる場合は、チェックされた例外をスローします。
-
- プログラム製品には明確な条件付き制約があり、検出可能なビジネス例外を宣言できます
例外の統一された分類
- 異常な変換
- 例外情報処理
- 論理的アサーション
- パラメータの合法性の検証
- 返された結果の有効性
例外キャッチ
例外を一律に傍受する
- 目的：あいまいな異常がシステムから流出するのを防ぎます
- RPCサービス応答の傍受
- Web制御応答の傍受
- HttpAPI応答の傍受
一般的なエラー処理方法
- 直接異常にならないでください
try {
new String(source.getBytes("UTF-8"), "GBK");
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
- 正しい取り扱い
try {
new String(source.getBytes("UTF-8"), "GBK");
} catch (UnsupportedEncodingException e) {
throw new RuntimeException("环境不支持UTF-8",e)
}
- ビジネスは情報を提供しません
public class DuplicateUsernameException extends Exception {
}
- 例外処理ごとにコードを定義し、すべてのビジネス例外を統一された例外に置き換えます
public class ServiceException extends RuntimeException {
public ServiceException(Exception e) {
super(e);
}
public ServiceException(String message) {
super(message);
}
}
間違い：
1。ビジネス例外を明確に定義する必要があります
。2。可能な限りcheckedExceptionとして宣言する必要があります。3。特定のビジネス番号を提示する必要があります。
正しい方法：明確に定義されたビジネス例外
PS：堅牢なシステムの異常な判断は特に重要です。開発が完了したとは思わないでください。実際、開発プロセス中、「正面玄関」は装飾と同じくらい明るく、「背面玄関」も装飾と同じくらい明るくなければなりません。制御されます。他の誰かが「正面玄関」から入らず、「裏口」に斧を入れるためだけに、ドアに入るための鍵を要求した場合はどうなりますか？