28

node.js を数週間使用した後、node.js サーバー エラーと、PHP などの通常のサーバー側言語との間に違いがあることがわかりました。

簡単な例: 何らかの理由で当社の Web サイトでエラーが発生した場合。

in PHP
ユーザーがサーバーと MySQL に無効なデータを送信すると、MySQL はその特定のユーザーにエラーを出力し、アプリケーション全体がダウンすることはありません。

ユーザーがサーバーとMySQLに無効なデータを送信すると、 nodejs
サーバーがダウンし、すべてのユーザーが切断され、ユーザー間の接続がなくなります。

これは本当に大きな問題です。大規模な Web アプリケーションでは、Nodejs サーバーのダウンを回避するためにすべてのエラーを処理することは不可能です。問題は、
特定の出力などに対する未知の致命的なエラーや例外を処理する方法があるかどうかです。

4

2 に答える 2

50

プロセス オブジェクトでuncaughtExceptionイベントを使用して必要なことを行うことができますが、他の人が言ったように、ドメインと正しいレベルでのエラーのキャッチ/処理が推奨されます。

process.on('uncaughtException', function(err) {
  console.log('Caught exception: ' + err);
});
于 2013-11-11T17:05:55.690 に答える
4

ルート内のリクエスト データを検証し、エラーをキャッチし (sync 操作であるため、ここでは try-catch が機能します)、適切な HTTP ステータス (400 など) を呼び出し元に返してエラーを処理し、エラーをログに記録する必要があります。Express を使用している場合は、Express がすべての同期例外をキャッチし、集中的に処理できるため、try-catch を使用する必要さえありません。

個人的には、 process.on('uncaughtException') を使用して検証エラーをキャッチすることは、次の 2 つの主な理由から、ニーズに最も適しているとは思いません。

  • この場所では、エラーが発生した場所のコンテキストがなく、発信者に応答を返すことができません
  • どのタイプのエラーが発生したかわからない場合は、プロセスを再起動することをお勧めします。無効な入力のためにプロセスを再起動しても意味がありません。たとえば、この方法では、外部呼び出し元 (DDOS) に対してアプリをダウンさせるのは簡単すぎます。

その他のエラー処理のベスト プラクティスについてはこちらを参照してください。具体的には箇条書き 4、6、および 10 を参照してください。

于 2016-05-31T13:28:36.983 に答える