3

SOAP サーバーに依存してコンテンツを生成するアプリケーションがあります。さらに、サイトへの認証は別の LDAP サーバーに基づいています。これらのいずれかがダウンしているか応答していない場合、サイトがダウンしていることは明らかです。

サイト管理者向けのエラー レポートを作成し、サイトがダウンした場合にユーザーに適切なメッセージを表示できるように設計しようとしています。エラー報告は、実際には単なる電子メール、データベースへの挿入、または PHP のサーバー上のテキスト ファイルへのログ $_COOKIE、$_SERVER、$_SESSION、$_REQUEST に加えて、SoapFault 例外の可能性があります。この情報は、サイトで潜在的な問題が発生した場合にデバッグするのに役立ちます。

現在、私のサイトは次のように設計されています。

SoapClientInterface (defines soap functionality)
      / \
       |
       |   implements
       |
Client (the client implementing the interface, try/catch blocks on all soap calls here) 
      / \
       |
       |  extends
       |
 Authorization (asserts soap objects returned from server/ requests going to server 
               are appropriate for the user performing the request) 
      / \
       |
       | extends
       | 
  {all children classes using the soap interface defined on this level}

上記の貧弱な図から:-)私はsoapfault例外のtry catchブロックをすべて含むクラスClientを持っており、catchで2つのことを行う最善の方法を考えています:1.アクションが失敗したことをユーザーに通知します(私のすべての機能は if/else ブロックにあり、操作が失敗したと判断した場合は、ユーザーをステータス ページにリダイレクトし、アクションが失敗したことを通知します.
2. デバッグのためにサイト管理者に状況を報告します (現時点でこの機能はステータス ページで定義された単純な関数で、ステータス ページがエラー コードを取得すると、Cookier、Server、Session、および Request 変数をダンプし、これをサイト管理者に電子メールで送信します。

これに関する提案をいただければ幸いです。明確化が必要な場合は、お問い合わせください。

編集: Web プログラミングの経験では、私のアプリケーションは通常、アクションが発生したページにユーザー アクションのステータスを表示し、他の場所にリダイレクトしません。ユーザー アクションを実行し、すべてのステータス メッセージに対して別のページにリダイレクトするようにアプリケーションをコーディングしたのはこれが初めてです。すべてのサイト アクションに対して 1 つのステータス ページを用意することや、アクションが発生したページのステータスを報告するクラス/関数を用意することにメリットがあると考える人はいますか? （ステータスページのデザインを独自に考えることと、エラーを報告する方法とそうでないことについて質問しています。）

4

1 に答える 1

1

まあ、個人的にはエラー次第だと思います。私の経験では、3 種類の例外があります。無視できるもの、回避できるもの、および実行を終了するために使用するもの (file_not_foundファイルを削除しようとしているだけの場合は例外を無視できますresource_not_available。リソースの代替ソース、およびdatabase_connection_failureバックアップがない限り、例外はアプリの終了を必要とします)...どのタイプの例外がキャッチされたかによって、それをどうするかが決まります。

個人的には、グローバル例外ハンドラーをインストールします...次に、catch ブロックで、リクエストをクリーンアップするか、別の方法で処理するか、続行するか (回復可能な例外の場合)、または可能であれば例外を再スローするかを選択できます。適切に処理しない (クエリ エラーなど)。例外がスタック (グローバル ハンドラー) の一番上にある場合は、エラーをログに記録し (これにはデータベース テーブルを使用します)、500 内部サーバー エラーをスローします。

エラーのリダイレクトに関する限り、私はそれを我慢できません。エラーが一時的なエラーである場合、ページを更新できないのはなぜですか? もう一度やり直すために、なぜ戻らなければならないのですか（できるとしても）...

バッファを適切に出力している限り、ほとんどの場合、機密情報をユーザーに表示せずにエラー ページをレンダリングできるはずです (致命的なエラーに対しては何もレンダリングできないため、ほとんどと言えます)。 HTTP仕様を壊しています（適切な「エラーが発生しました」ステータスヘッダーではなく、エラーが発生した現在のページからの一時的なリダイレクトがあると言っているため）...

于 2010-08-16T12:36:46.137 に答える