5

私はかなり大規模なプロジェクトに取り組んでおり、stackoverflowや他のWebサイトで例外について多くのことを読んでいます。その結果、100％正しいか間違っているかがわかりました。無効なユーザー入力に対して例外をスローするものもあれば、そうでないものもあります。ランタイムエラーに対してのみ例外をスローするものもあれば、スローしないものもあります...

個人的には、無効なユーザー入力に対しても例外をスローする方法が好きです。

今、私の問題は、たとえば、別のユーザーのステートメントにコメントできるユーザーがいることです（たとえば、彼/彼女のお気に入りの音楽など）。すべてのユーザーは一度だけコメントすることができます。ここで、コメントのデータベースエントリを作成する関数は、ユーザーがそのステートメントにすでにコメントしているかどうかを確認します。はいの場合、例外をスローします。通常、私はこの例外にExceptionStatementAlreadyCommentedという名前を付けますが、このプロジェクトには他にも多くの関数があり、このような特定の例外を常に作成すると、約100〜200の例外が発生します。

これはパフォーマンスに影響しますか？__autoload関数を介して必要なクラスを自動ロードするため、実際の例外は必要な場合にのみロードされます。

このような例外に名前を付けるのは良い方法ですか？以前は、例外をキャッチしたときに、キャッチしたくない例外をキャッチすることがあったため、さまざまなエラーに対して1つの例外を使用するのに問題がありました。

本当にありがとうございました！

よろしくお願いします、

フレディ

4

3 に答える 3

9

私の気持ちは、あなたが例外を使いすぎているということです。名前で参照されるように、予期はExceptional Circumstancesの下でのみスローされる必要があります。

アプリケーションのフローを制御するために例外を使用しないでください。ユーザーが不正なデータを入力したり、正しいユーザー名とパスワードを入力しなかったりすることは、例外ではなく、アプリケーションの通常の流れの一部と見なされます。

データベースに接続できないなど、アプリケーションの全体または一部が使用できなくなる可能性がある例外的な状況でのみ、例外をスローする必要があります。

このようにして、キャッチして再スローする必要があるほど多くの例外がシステムに発生することはありません。

さまざまな例外を設定することをお勧めします。たとえば、RedBean ORMを使用してデータベースと通信し、次の例外を使用しています。

  • RedBean_Exception_Security (セキュリティ例外が発生した場合)。
  • RedBean_Exception_SQL (不適切な SQL 構文またはその他の問題が発生した場合)。

例外について具体的すぎると、多くの混乱が生じる可能性があります。たとえばmissing sql column、bad syntax、missing value、 などの例外があると、非常に扱いにくくなる可能性があります。しかし、私が を持っていてSQL_Exception、上記のすべてにその例外を使用すると、管理がはるかにきれいで簡単になります。

パフォーマンスに関しては、多くのクラスをロードする必要があるため (それらは外部ファイルにあると想定しています)、アプリケーションに負担がかかる可能性があります。これは、 APCを使用して、解釈された PHP コードをメモリにキャッシュすることで部分的に軽減できます。しかし、これはプロファイリングなしではわかりません。

于 2012-07-13T08:52:16.810 に答える
3

たとえば、最も一般的なものから最も具体的なものまで拡張する例外のツリーを持つことは良いことですStatementAlreadyCommentedException。のような、より一般的なものから継承します。InvalidUserInputExceptionAlreadyExistsExceptionException

このようにして、検索している例外よりも具体的なすべての例外をキャッチできます (必要になった場合)。( をキャッチできException、考えられるすべての例外をキャッチできます。キャッチできAlreadyExistsException、それを拡張するすべての例外をキャッチできます。

于 2012-07-13T08:51:02.880 に答える
2

考えられるエラーの種類ごとに個別の例外クラスを作成することは意味がありません。例外クラス名はエラーを大まかに説明し、各クラスには適切な変数を設定して、例外メッセージとともに正確なエラーを説明できるようにする必要があります。

現在のアプローチがパフォーマンスに影響を与えることはありませんが (少なくとも例外クラスの数は影響しません)、保守性に影響を与える可能性があります。利点。

を直接拡張する 200 の例外クラスを生成するのではなく、よく考え抜かれた例外階層\Exceptionを作成すると、事態はさらに良くなります。

たとえば、 for each ケースRecordAlreadyExistsExceptionではなく、すべての同様のケースに対して例外のようなものを使用します。ThisTypeOfRecordAlreadyExistsException

于 2012-07-13T08:50:15.363 に答える