この場合、呼び出し元でレスポンス（nullなど）を処理するのではなく、カスタムエラーを投げるのがよいでしょうか？

Question

タイトルごとに。あまり言いたくない。

EDITここで示唆したように、私は

• のいずれかに、より理にかなっているかどうかを知りたいのですがしたユースケースは、特定のように、エラー または
• リターン「ヌル」を（スローですエラーが関係ない）

角4サービス

における方法に包まれたDB操作

return this._db.upsert(item._id, (doc) => item) 
    .then(response => { 
     return response; 
    }) 
    .catch(specificErrorProvided => { 
     // return null or throw Error? (the user is not concerned with the specific error) 
    }); 

Answer 1

最終的なエンドユーザーにとっては、カスタムエラーは素晴らしいです。たとえば：

505内部サーバーエラー

は以外のユーザーに、より不明瞭になります。

は今、サーバーに到達することはできません。管理者に連絡する

その他の使用例は、デバッグの場合ですが、まれです。私は彼らがエンドユーザー向けに作られたと言います。

あなたが示した場合にはEDIT

、カスタムエラーは、実行するアクションを決定します。 nullを返すことができる関数が複数ある場合は、エラーをログに記録してから、の束を得る以外に、次に取るべきステップを決定するために、例えばdbFunError2のような詳細な応答を返すことができます。

希望すると、これはわかります。