7

他の人が使用するpub/sub Mediatorライブラリを開発していますが、エラーの処理方法がわかりません。

コードの例を次に示します。

/**
 *
 * @param String channel Channel to subscribe
 * @param String|function callback Function name or callback
 * @param String context Context to bind function to
 * @param Boolean once True to subscribe once
 **/
this.subscribe = function (channel, callback, context, once) {

    if (!_.isObject(context)) {
         context = window;
    }

    if (!_.isFunction(subscription) && !_.isFunction(context[subscription])) {
        throw new Error('Function passed as callback to channel subscription named  ' + channel + ' seems invalid!');
    }

    // Everything ok, add to channels object
    channels[channel].push({fn: subscription, context: context || this, once: once});
}

このメソッドはライブラリの一部です。APIは、チャネル名と有効なコールバック（関数名、ラムダ、またはコールバックのいずれか）を想定しています。

チャネル引数が文字列でない場合、ライブラリはすぐに停止します。無効なコンテキストが渡された場合、ウィンドウが想定されます。これら両方のパラメータの間違いは簡単にデバッグできます。

ただし、無効なコールバックが渡されると、イベントが発生する（チャネル公開が行われる）までエラーが伝播されます。pub / subシステムでは、たとえば、イベントがめったに発生しない場合、これはデバッグの悪夢になる可能性があります。

だから私の質問は...

この特定のシナリオでは、私が他の人にjavascriptライブラリを開発していることを考慮に入れて、次のことを行う必要があります。

  • それ以上のエラー伝播を防ぐためにエラーをスローしますか？
  • false / undefined / -1を返し、サブスクリプションを登録しませんか？
  • デバッグをサードパーティの開発者に任せて、どこかで死ぬように通常どおり続行します

注：同様の質問がありますが、私の状況は少し異なり、提供された回答は私の精神を安心させませんでした。

4

3 に答える 3

1

この答えは私の意見であり、私が従うものだと思います。エラーをスローして、ライブラリのコンシューマーにエラーを処理させるかどうかを自問する必要があります。エラーが回復できないものである場合、エラーをスローする必要はありません（JSで）。ライブラリは代替に適切にフォールバックできる必要がありますが、特定の関数に対してそれができない場合は、undefinedを返す必要があります。ほとんどのJS開発者は未定義をチェックしますが、ライブラリ関数を使用しているときにチェックするのはかなり一般的な方法です。イベントを処理できない場合、通常、falseを返すのはイベントハンドラーで行われます。

于 2013-02-07T16:05:38.913 に答える
0

オプション #3 は避ける必要があります。少なくとも、return false;. イベントが発行されないことを期待して、無効なコールバックを登録することもできます (何か問題が発生したため)。この「すべてがうまくいかなかった場合のサイレント フェイル」は、pub/sub の例には実際には当てはまらないかもしれませんが、ユースケースはあるかもしれません。

オプション #2 は良さそうです。どういうわけか、callbackパラメーターを明示的にオプションにします。これは、ライブラリの機能である可能性があります。ユーザーがサブスクライブする理由があるかどうかわからない場合、とにかくそれを行っている場合、ユーザーはそのテストを省略できます。console.warn()これをデバッグ バージョンのメッセージと組み合わせることができます。

本当に予想外のことが起こった場合は、オプション #1 を選択する必要があります。非常に説明的なカスタム エラー メッセージで失敗することができます。これは、コールバックが真実のオブジェクトであるが呼び出し可能ではない場合、またはチャネル引数がブール値または何かである場合に当てはまります-インターフェース設計がどれほど閉じているか/提供するオーバーロードの量に応じて(あなたのケースでは文字列を受け入れることができます)コールバック、またはチャネル文字列の配列などとして評価されます)。

于 2013-02-07T16:32:53.147 に答える