0

一般に、ソフトウェア設計において、データベースやファイルなどのリソースに問題やエラーが発生した場合、次のどのオプションが優先されますか?

  1. エラーメッセージを表示
  2. エラー メッセージを表示せず、リソースが空であるかのように動作します (例: GUI コンポーネントを設定しません)]

たとえば、空の DataGrid が表示された後に文句を言うべきか、それともエラー メッセージが表示されるべきか? どちらが良いですか？

4

4 に答える 4

2

私はこれをどちらか/またはとして見ません。また、システムのすべての「ユーザー」を考慮する必要があります。

まず、UI を検討します。不自然な一般的なケースを考えてみましょう: サービスを呼び出すことによって UI を生成し、そのサービスはいくつかのデータベース (たとえば、「現在のデータ」と「履歴データ」) データベースを使用します。

少なくとも次の可能性があります。

  • すべてが機能し、データが取得されます
  • それはすべて機能しますが、たまたまこの特定のクエリのデータがありません
  • サービスにアクセスできません
  • サービスが呼び出されましたが、1 つのデータベースがダウンしています
  • サービスは呼び出されますが、両方のデータベースがダウンしています

次に、アプリケーションのセマンティクスも考慮してください。すべてのデータを取得できない場合、アプリケーションは「劣化」モードで続行できますか? たとえば、履歴を照会することはできませんが、新しいアイテムの作成を止めることはできません。

ここで役割についても考えてみましょう。UI を使用する人がいて、問題を把握して修正する必要があるサポートおよびメンテナンスの人もいます。

私の一般的なルール：

  1. 最初の障害データのキャプチャ: 最初にエラーを検出したコンポーネントは、エラーを詳細に記録する必要があります。したがって、サービスを起動し、データベースを停止すると、問題がログに記録されます。サービスがダウンしています。UI は問題をログに記録する必要があります。このログは、サポート ロールを対象とする技術記録である必要があります。
  2. UI は寛容である必要があります。可能であれば、劣化モードで実行してください。そのため、サービスがダウンしているが (たとえば) ローカルで作業できる場合は、空の画面を表示して続行します。しかし ...
  3. 常に問題を示す: 「このクエリのデータがありません」および「データベースが利用できない」場合は、どちらも空の画面になることがあります。ユーザーは、表示のステータスを知る必要があります。完全な情報が表示されているのか、部分的な情報が表示されているのか (たとえば、1 つの DB がダウンしているため)、または情報が利用できない (たとえば、サービスまたは両方の DB がダウンしているため) かを知る必要があります。したがって、画面のどこかに「ステータス」フィールドがあります。などのメッセージを伝える

ヒストリカ データは現在利用できません

また

情報の取得中に問題が発生しました。問題が解決しない場合は、サポートにお問い合わせください...

于 2010-07-22T05:29:11.983 に答える
1

各オプションにはいくつかの落とし穴があります

エラー メッセージの表示

これは、アプリケーションがテスト段階または公開テストにある場合に特に役立ちます。また、クライアントがエラーに遭遇した場合、詳細をコピーして転送することもできます。

ただし、このエラー メッセージは非常に見苦しく (コール スタックなど - ASP.NET を覚えていますか?)、非常に大きくなり、クライアントが詳細をコピーするのが困難になることがあります。

エラーメッセージを表示せず、何も起こらなかったかのように振る舞う =)

これは、エラー メッセージがソフトウェアの UI 設計を混乱させたくない場合に役立ちます。ただし、クライアントが実際のエラーと GUI 上で何も区別できない場合、それは難しくなり、さらにエラーが発生しやすくなることを思い出してください。エラーはそこに残り、何も修正されません。

私のスタンド

両方の長所を活用してください。実際、最新のアプリケーションのほとんどは、非常に優れたエラー処理プロセスを備えています。Mozilla Firefox 3 の例を取り上げます。

  1. 致命的なエラーが発生し、Firefox がクラッシュする
  2. エラーがキャプチャされ、エラー レポートの形式としてファイルに保存されます
  3. ユーザーに謝罪するエラー報告アプリケーションがポップアップ表示される
  4. エラー レポートをソフトウェア開発チームに送信するかどうかをユーザーに確認します。
  5. 次に、アプリケーションを再起動するかどうかをユーザーに尋ねます

または、エラーが警告または重大度の低い場合:
簡単なエラー コードを表示し、そのアクションでエラーが発生したことをユーザーに伝えます。次のようなもの:「RequestSalary() 行 2 でエラー 123」

于 2010-07-22T03:55:21.273 に答える
0

私が通常使用する練習は次のとおりです。

  1. ユーザーエラーが原因でエラーが発生しなかった場合は、エラーを静かに処理するようにしてください。
  2. 外部の問題 (インターネット接続がないなど) が原因でエラーが発生した場合は、ユーザーに警告する必要があります。
于 2010-07-22T03:51:48.167 に答える
0

IMO メッセージを表示する必要があります (ただし、「java.io.IOException: Connection timed out」のようなものではなく、ユーザー フレンドリーなものです)。データの取得中にエラーが発生したことをユーザーに通知し、役立つヒントを提供するメッセージ ボックスを表示できます。のような: しばらくしてから試して、ネットワーク ケーブルなどを確認してください。また、ユーザーが実際のエラーとスタック トレースを送信するエラーを報告できるようにします (エラー報告はアプリに組み込まれています)。

于 2010-07-22T03:53:24.287 に答える