コアポイント
Exception
のトップは、「問題」があると言うことと同等であり、コードは何が起こっているのかわからない。代わりに、カスタム例外を常にスローして、現在の状況のコールコードに通知する必要があります。 PHP 5は、予期しないイベントを示すために(スローされたエラーとは対照的に)スローおよびキャッチできる特別なクラスである例外処理メカニズムを導入します。エラーとは異なり、例外は、呼び出しコードによって処理されることを目的としています。例外がスローされると、現在のスコープのコードが実行を停止します(throw
ステートメントが実行された後の行はありません)、コントロールは最初の一致する例外ハンドラー(キャプチャブロック、設定された例外ハンドラー、または言語によって提供される例外ハンドラー)。コードの実行は、例外がキャッチされた場合にのみ、そこから続きます。この記事は、エントリレベルでの例外を説明することではなく、例外をより適切に使用する方法に関するアドバイスを提供することを目的としています。以前に例外を使用したことがない場合は、PHPマニュアルに相談するか、私の友人が書いた本「PHP Master:Writing Condeded Code」を読む必要があるかもしれません。
エラーは例外ではありません
例外について学んだかもしれませんが、PHPエラーと(カスタム)例外の違いについて疑問に思うかもしれません。ロジックは実際には非常に単純です。エラーは回復不能であり、メインの実行ループで発生し、環境の安定性を示します。たとえば、スカラー値に配列としてアクセスしてE_NOTICE
を上げようとすると、コードに問題があることを意味します。継続的な実行が安全であるという保証はありません。この状態は、実行中に修正することはできません。パーサーによって発見された予期しないT_IF
によってE_PARSE
がトリガーされると、これが物事の安定性にどのように影響するかを理解できます。一方、例外は回復可能であり、メインの実行ループの外で発生する可能性があり、システムの安定性を示していません。 「指定された入力でリクエストを完了することはできないため、その情報が自由にLengthException
を投げることができます。したがって、現在の値で指定された命令を完了することはできません。これは、環境が不安定であることを意味するものではなく、パディングまたは切り捨てによってコードが値の長さを調整する必要があることを意味します。コードはこの例外をキャッチし、値を更新し、再試行することができます。
すべての例外が例外これは、答えるのが最も難しい質問の1つです。例外をスローする必要があるのは正確ですか?もちろん、例外は前の段落の3つのルールに準拠する必要があります。破損したメモリに遭遇したときに例外を投げることは非常に悪い習慣です。環境が実行を継続するために安全でないことが判明するため、PHPができるだけ早く中止できるように、コードは代わりにエラーをスローする必要があります。ただし、エラーが不要であっても、すべての非成功した状況には例外は必要ありません。つまり、すべての失敗した状況が例外ではありません。 「異常」という言葉は、通常の操作でも標準でもないアクションと、通常の状況や予想される状況から逸脱する異常を指します。元同僚は、夕食時に、彼らの会社が使用しているXML/RPCサービスがすべての公共面でのバックボーンであると私に言った。その後、建築家は例外と、非成功しない状態を示す際の彼らの利便性について学びました。この柱は、他の機能に加えて、単一のサインオン機能を提供します。データベースに直接アクセスする代わりに、WebアプリケーションはXML/RPCサービスを照会します。これは、すべてのWebアプリケーションにサービスを提供する集中データストアに基づいて応答します。有効な資格情報が提供されると、成功したステータスが返されます。問題が発生すると、例外がスローされ、障害の理由を示すメッセージが表示されます。キャプチャしやすいと、印象的で光沢のあるエラーメッセージでメッセージをユーザーに表示できます。しかし、ユーザーは誤ったユーザー名および/またはパスワードを提供していることを本当に期待から逸脱していますか?私のプロジェクトでは、私が扱うユーザーは完璧ではありません。彼らは物事をタイプしたり忘れたりします。誤った資格情報を取得することは非常に一般的であり、有効な資格情報よりもさらに一般的です。検証資格情報は、システムへのログインの予想される動作であるため、この場合、XML/RPCサービスは、検証が成功しているかどうかを示すステータスを返す必要があります。資格情報は失敗しますが、検証プロセス自体は依然として正常に実行されます。検証プロセスが正しく実行されない場合、他の問題があります。たぶん、データストアはアクセスできない、または他の何かです。データストアなしでは実行できないため、ログインシステムがデータストアに接続できないことは非常にまれです。したがって、これには例外をスローする必要があります。注:一部の人々は、ログインシステムがデータストアに接続できないことが環境が不安定であり、したがってエラーが発生することの兆候であると主張する場合があります。ただし、システムにログインすることは、データストレージのエラーを発生させる責任はありません。逆に、データストレージコネクタ/ラッパーが必要と思われる場合、エラーを発生させる必要があります。一般的に言えば、例外を開発者が介入し、表示し、それらを処理しなければならない状況と考えることができます。例外シナリオで発生するコードは、それ自体でこれを行うことはできません。これはおそらく、開発者がコードを調べたことであり、彼らがそれを処理する方法は、それが起こったときにそれを起こさせることです。ネットワークオペレーションセンターにすべての例外をメールで送信しないでください。できることと処理すべきことを処理すると、例外は実際に実行を継続できない場合にのみスローされます。
「問題 "
数年前、私がヨーロッパをハイキングしていたとき、私はギリシャの駅で忘れられない光景につまずきました。ロッカーエリアの1つは爆弾のように見え、地面にドアが散らばり、半分はヒンジにぶら下がっているか、壊れていました。後で、彼らがロッカーエリアを削除していることを知りましたが、この領域が非アクティブ化されていることをクライアントにどのように伝えたかは注目に値します。中央の部分にはたくさんのテープがあり、「問題」という言葉で紙を貼り付けました。技術的には、これは完全に正しいです。明らかにロッカーに何か問題があり、状況は顧客に通信することで処理されました。あなたはそれを面白いと思うかもしれませんが、実際、あなたはあなたのコードに頻繁にこれを見るでしょう。 Exception
を投げるだけで、基本的に「問題」と言っており、コードは何が起こっているのかわからない。 Exception
はそれぞれの例外の基本クラスですが、独自のタイプで拡張できます。例外のより広いコレクションはSPLライブラリにありますが、これは限界からはほど遠いものです。 Zend FrameworkやSymfonyなどの主要なPHPフレームワークを見ると、ほぼすべての異なる状況にカスタム例外を使用することがわかります。これらすべてのファイルを作成して、動的にロードしてすべての異なるタイプを維持できるようにするのは少し面倒ですが、これにより、そのフレームワークとそのフレームワークの消費者に対して何が起こるかを細かく制御できます。あなたがException
だけを投げるなら、あなたは何かが間違っていることを確認することができ、あなたもあきらめるかもしれません。これは、キャプチャブロックをサイレントオペレーターとして使用し、誰かがこの状況を何らかの形で修正できることを期待していることをあきらめるだけで、それらがエラーである方法で例外を使用することを意味します。
グローバルキャプチャ
非カスタムの例外を使用して、考えられるすべての例外をキャッチすることが悪い考えである場合、なぜ言語はこれを許可するのですか?特定の例外、つまりグローバルなキャプチャルールを常に使用およびキャッチするルールには、1つの例外があります。グローバルキャプチャブロックは最高レベルのキャプチャブロックであり、そのレベルに泡立つすべての例外をキャッチする必要があります。 PHP自体には(「致命的なエラー:猛攻撃の例外...」というメッセージが表示されていますか?)が含まれていますが、カスタムハンドラーでオーバーライドしてフォールバックとして機能します。このハンドラーをset_exception_handler()
関数で設定することができます。そのため、「catch (Exception $e) {
」などの行を禁止するPHPMDルールセットにルールを追加できます。これが、生産コードにある必要がある一般的な例外ハンドラーの唯一の理由であり、まだキャッチされていないException
クラスのすべてのインスタンスをキャプチャします。他のハンドラーは、具体的であり、例外に限定されている必要があります。例外は、処理方法と責任を負う方法を知っています。ここで慎重に進むと、ハンドル可能な例外を一度泡立たせます(そしてコードで修正します)。
概要
要するに、例外は、特定の入力で要求された命令をコードに完了できない場合にのみスローされます。常に、現在ケースにある呼び出しコードを実際に指示するカスタム例外をスローし、他のコードを呼び出す場合は、処理できるものと処理できる例外のみをキャッチします。これにより、ブラックボックス(カスタム例外)のようにコンポーネントが少なくなり、コンポーネントを統合する開発者がコードを変更する必要がある可能性が低くなります(そうすべきではない例外をキャッチしないでください)。私たちは常に顧客/マネージャーが具体的であるように言いますが、私たちも具体的であるべきです!
(フォトリアからの写真)
PHP例外処理に関するよくある質問
はい、PHPで例外を再スローすることができます。これは、どういうわけか例外を処理したいが、より高いレベルの例外ハンドラーをキャッチしたい場合に非常に便利です。例外を再スローするには、キャッチブロックのスローステートメントを使用してください。
PHPでは、キャッチブロックでERROR_LOG関数を使用して例外を記録できます。これにより、メッセージやスタックトレースを含む例外に関する情報を指定されたログファイルにログに記録できます。
PDOExceptionは、PDO操作でエラーが発生したときにスローされる例外です。 PDO(PHPデータオブジェクト)は、PHPでデータベースにアクセスするための一貫したインターフェイスを提供するデータベース抽象化レイヤーです。 PDOExceptionは、SQLSTATEエラーコードやデータベースドライバーのエラーメッセージなどのエラーに関する情報を提供します。
PHPでは、カスタム例外ハンドラー関数を定義し、set_exception_handler関数を使用してデフォルトの例外ハンドラーとして設定することにより、猛攻撃の例外を処理できます。この関数は、トライキャッチブロックによってキャッチされていない例外がスローされるたびに呼び出されます。
以上がPHPマスター|例外的な例外の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。