3

私は最近、 http://phpmaster.com/exceptional-exceptions/で記事を読み、例外について次のように述べました。

呼び出しコードがメッセージを読み取ることは決してありません。メッセージが良いのは、開発者だけです。

W3Schools の Web サイトでは、例外メッセージがキャッチされたときに例外メッセージを出力する例が示されているため、混乱しています。私はhttp://www.phpmaster.comから多くのことを学び、彼らの言うことを信頼していますが、W3Schools も常に信頼できるので、どちらを行うのが正しいのでしょうか?

例外メッセージはユーザーに出力されるはずですか、それとも開発者向けのものですか? 多分それはそれほど重要ではなく、害を及ぼすことなく両方の方法で使用できますか?

4

5 に答える 5

2

シナリオにもよりますが、最大の問題はセキュリティです。開発者が例外をスローするとき、彼らは通常、何が正確に間違っているかについてのいくつかの有用な情報をメッセージに含めようとします。彼らは、その情報が現在の状況であなたによって機密であると見なされるかどうかを知ることができません。

例として、ログインフォームのあるWebサイトがあるとします。データベース内のUsersテーブルが欠落していて、誰かがログインしようとした場合、スローされる例外は次のようになります。Unable to find table users in database MyDb (db.mysite.com)

そのメッセージが悪意のあるユーザーに表示された場合、悪意のあるユーザーはデータベースの場所とデータベース/テーブルの名前を知っています。

このシナリオでは、一意のIDを使用して完全な例外をログに記録し、ユーザーにIDを表示して、必要に応じて後でフォローアップできるようにする傾向があります。

逆に、デスクトップアプリの場合は、逆に傾く傾向があります。例外メッセージはエンドユーザーに役立ちます（たとえば、Access Deniedユーザーが解決できる可能性があるものです）。それでも、例外メッセージが役立つかどうかはわかりません（ala ）。そのため、例外をより役立つメッセージ（たとえば）でラップし、すべての内部例外のリストを公開するReference not set to an instance of an object傾向があります。Unable to connect to databaseこれは、ユーザーが理解できるメッセージを受け取ることを意味しますが、セキュリティリスクではなく、利用可能な場合はより有用な情報を受け取る可能性もあります。

于 2013-02-23T16:42:22.150 に答える
1

明確な答えはありません。メッセージが提供する情報によって異なります。
メッセージに機密情報が含まれていない場合は、メッセージをクライアントに出力できます。

$codeエラーをクライアントに出力するためにパラメーターを使用するのが好きです。
そんな感じ：

function clientError(Exception $e) {
    $error = 'Unknown error!';
    switch ($e->getCode()) {
        case 404:
            $error = 'Not found error!';
            break;
        case 403:
            $error = 'You cannot access this page!';
            break;
        ...
        ...
    }
    return "$error [error code: {$e->getCode()}]";
}

エラー ログにエラー メッセージを保存し、clientError をクライアントに出力します。

try {
    if (!$user->isMember()) {
        throw new Exception("Guest {$user->id} tried to access to newPost.php page", 403);
    }
}
catch (Exception $e) {
    $errorLog->newError($e);
    echo clientError($e);
}

この例では、エラー ログに次の行を追加する必要が あり
ます 。

于 2013-02-23T16:52:40.170 に答える
1

ほぼ正しい。Stackframe などでハッカー タイプを提示したくないことは確かです。ユーザーにそれらを提示することも、それほど役に立ちません。そうは言っても、提示されたとおりにこのアドバイスに従うことは、罠に陥ります。

取得する例外クラスが一般的すぎる場合があり、それを識別する唯一の方法はテキストをテストすることです。OLE はそのための古典的なものでした。何があってもOLEDB例外が発生したSQLステートメントを実行します。もう1つの関連するものは、catch endを試してみて、スローされる唯一の例外があなたが考えていたものであると想定すると、ユーザーが呼び出して「ドキュメントの保存に問題があります」と言った場合です。 」、これは一連の問題のいずれかである可能性があります。

他に何をしても、生の例外とスタックフレームをログに記録します。当たり前のことですが、あまりにも多くの人がこの罠に陥ります。

あなたが提示したメッセージがまったく役に立たないルートになるまで、問題を軽視しないでください。

開発者の例外でさえ、0000000 でのアクセス違反 0000000 は良いものであり、「Unknown ole error(5)」は見事に愚かであり、これまで迷惑な msi の「エラー 1603」でした。

于 2013-02-23T16:59:11.297 に答える
0

W3Schoolsに関して： http：//w3fools.com/

例外は開発者専用です。攻撃者がサイトをハッキングするのに役立つ情報が含まれている可能性があり、見栄えがよくありません。期待していた場合は例外をキャッチし、ユーザーが理解できるエラーメッセージを表示するなど、ユーザーが期待することを実行します。例外が発生することを予期していなかった場合は、修正する必要のある問題があります。

キャッチされない例外は「バグ」とも呼ばれます;）

于 2013-02-23T16:41:46.017 に答える
0

ほとんどの場合、例外はプログラミングの経験が不足しているためエンドユーザーには役立ちません。独自の例外を処理し、エンドユーザーに明確なメッセージを送る必要があります。

于 2013-02-23T16:42:23.557 に答える