1

クラス関数のチェーンでの使用が制限されていることを発見しました$class->setUser('foo')->getInfo()(悪い例) が、チェーン内の呼び出しの 1 つから発生したエラーを処理する方法を理解するのに苦労しています。

たとえば、エラーが発生して false が返された場合setUser()、返さ$thisれず、別の関数を呼び出すことができないため、エラーが表示されます。

私が実際に気付いたこと (これが間違っている場合は修正してください)、エラーが発生した場合に例外をスローすると、次の関数が実行されてエラーが発生するのをsetUser()防ぐことができますか?getInfo()

これは、チェーンを使用しない場合でも、チェーンを使用するコードをデバッグできるように、少なくとも知っておくと便利な知識です。

4

2 に答える 2

3

はい、この場合、例外をスローすることはおそらく良い考えです。チェーンのどこでエラーが発生したかを特定できます。

これがどのように機能するかの例を次に示します。

try
{
    $class->setUser('foo')->getInfo();
}
catch(UnknownUser $ex)
{
    // setUser failed
}
catch(CannotFetchInfo $ex)
{
    // getInfo failed
}
于 2011-06-03T21:43:21.070 に答える
1

チェーンと同様に、1 つの要素が壊れると、チェーン全体が壊れます。

したがって、オブジェクトをチェーンしている場合、一方では非常にアクセスしやすいかもしれませんが、他方では、エラー (リモート接続、ファイルなど) が原因で物事が失敗する傾向がある場合、チェーンは扱いにくくなります。

そのため、予期したタイプの応答が返されずに失敗を通知しない限り、例外は役に立ちますが、チェーンが壊れているため、使用が制限されています。

ただし、例外をスローすることは、エラー処理 (チェーン内および独自のコードの開発) のために実行できる最善の方法だと思います。

例外をスローする利点は次のとおりです。チェーンにアクセスできるようにする構文を破棄する必要はありません。

コードに誤りがあるとしましょう。とにかく修正する必要があるため、例外をスローすることをお勧めします。

または、データ層がコード化されており、頻繁に失敗するとします。例外をスローすると、より多くの愛が必要な部分がわかります。

連鎖している汎用コードでは、これらの例外が中断します (いつでも例外をキャッチできますが、エラーを例外に変えることもできます)。もう十分に考えました。

そう、

  1. 例外は、チェーンのエラー処理の方法です
  2. 例外は、より高いレベルのデータ アクセスのチェーン構文を維持しながら、エラーのさまざまな原因を特定するのに役立ちます。

ただし、連鎖がどれほどうまく行われても、それがもはや意味をなさない点があります (「すべてと同様に」を追加する必要があります;))。私は連鎖の本当のファンだとは言いませんが、ファンではない私でも、自分のコードでこの原則を時々使用しています。簡単に記述できるコードを作成できるので、エラー処理に例外を利用します。「実際の」(tm) 問題には遭遇しませんでした。虚偽やそのようながらくたでチェーンを壊すよりもはるかに優れています.

理論的には、オーバーロードを介して任意のプロパティ/メンバー コール セット/取得を取得するオブジェクトを返すことができますが、これを操作するのが楽しい場合でも、実際の実際のエラーに対処するのに役立つよりも複雑さが増すだけだと思います。

したがって、エラーに連鎖すると、例外を使用すると実際にエラーが表示されます。そのための例外が設けられています。エラー (またはシグナル、動作) が原因で、アプリケーションの標準処理を中断する場合。

于 2011-06-03T22:02:22.127 に答える