0

私はしばらくの間NodeJSのZMQバインディングを使用してきましたが、そのようなエラーは発生しませんでした。

Error: Interrupted system call
    at Socket._ioevents (/path/node_modules/zmq/lib/index.js:144:22)
    at Socket._flush (/path/node_modules/zmq/lib/index.js:273:23)

今、私はトポロジーを作成する大きなシステムを持っています。私にとって、このようなエラーを考えると、トポロジのどのノードが失敗したかを確認するのは非常に困難です。アイデアは、このエラーをキャッチし、それが発生した場所をログに記録するために、ある種のtry/catchを配置することです。

これを行う方法はありますか？次のコードは機能しないと思います。

try {
    receiver.on('message', function(data){
        //do stuff  
    });
}
catch(e) {
    console.log("error " + e)
}

これらすべてのtry/catchを使用してソフトウェアの大部分を変更する必要があるため、この種のエラーをキャッチするための正しい方法であるかどうかを確認したいと思います（ほとんど確実ではありません）。

誰でもこれを確認できますか？そうでなければ、経験のある人なら誰でも、私が受けているエラーについて私に教えてくれるでしょうか？

ありがとう

編集：簡単なテストの後、99％このアプローチが機能していないことを確認できます。そのエラーがどこから来ているのかを知る方法はありますか？

2番目の編集：この問題は、ZMQのバージョン2.0からバージョン2.1へのアップグレードに関連している可能性があることを発見しました。これは変更ログhttp://www.zeromq.org/docs:2-1-upgradeへのリンクですが、以下は私が最も関心を持っている部分です。

In 2.0, ZeroMQ would ignore any interrupted system calls, which meant that no ZeroMQ
call would ever return EINTR if a signal was received during its operation. This caused
problems with loss of signals such as SIGINT (Ctrl-C handling), especially for language
runtimes. In 2.1, any blocking ZeroMQ call such as zmq_recv[3] will return EINTR if it
is interrupted by a signal.

それで、誰かが私のブロッキング呼び出しをラップして処理する方法を知っていますEINTRか？

4

1 に答える 1

1

try-catchブロックは、コールバック自体の登録のみをラップしていると思います。したがって、例外が実際に発生した場合、それを処理するためのtry-catchはありません。次のようになります

receiver.on('message', function(data){
    try {
        //do stuff
    }
    catch(e) {
        console.log("error " + e);
    }  
});

実際、ZMQ呼び出しを使用するコードは、例外が発生する可能性があるため、try-catchでラップする必要があります。GitHubで自分自身を確認できます。私はあなたの特定の例外がこのあたりで発生するかもしれないと思いますが、100％確実ではありません;-)

お役に立てば幸いです、乾杯;-)

于 2013-01-15T15:14:57.863 に答える