1

ネットワーク経由で JSON メッセージを取得するためにstomp.pyライブラリを使用しています。コールバックを使用してメッセージ処理を提供する、ここで提供する簡単な例を採用しました。

しかし、そのコールバックを変更したときに単純なエラーが発生しました。たとえば、JSON 文字列を解析しようとしたときに、json.loads() の代わりに json.load() を呼び出しました。

class MyListener(object):
    def on_message(self, headers, message):
        data = json.load(message)           ## Should be .loads() for a string!

通常はそれで問題ありません。AttributeError になり、トレースバックが表示されます。ただし、この場合、Python は次のように出力します。

ロガー「stomp.py」のハンドラが見つかりませんでした

...トレースバックもクラッシュもありません。それだけです。デバッグして何が間違っていたのかを見つけるのは非常に混乱します! 少なくとも次の行に沿った通常のトレースバックを期待していました。

Traceback (most recent call last):
  File "./ncl/stomp.py-3.1.3/stompJSONParser.py", line 32, in <module>
    [etc etc ...]

...リスナー全体を退屈させるのではなく。それは別のスレッドで発生したためだと思いますか？

解決したので、これはコールバックの一種のランタイム エラーのようなもので、エラーが発生したときに何か間違ったことをしたことを少なくとも知っていますが、何らかの間違いをするのではなく、間違いを犯すたびにそのエラーを吐き出すだけの場合便利なメッセージですが、コーディングが少し難しくなります。

これは何が原因ですか？そして、通常のより詳細なトレースバックを取り戻すにはどうすればよいでしょうか?

4

3 に答える 3

5

出力をキャプチャするために、 Python ロギング モジュールのログ ハンドラーがセットアップされることを期待しているようです。ロギングには多くの構成が可能です。しかし、単純なデバッグのために、次のようなものを使用します

import logging
logging.basicConfig(level=logging.DEBUG)

これにより、ログ レベル DEBUG 以上のすべての出力がキャプチャされます。詳細については、ログのドキュメントをお読みください:)

于 2013-03-06T14:58:20.273 に答える
1

ロガーを取得するための手順 (直接要求されているもの) は、こちらにありますが、詳細なトレースバックは抑制されています。

を呼び出しているコードをon_message見ると、そのブロックが . のtryないブロックにあることがわかりますexcept。

行 703 は、メソッドが実際に呼び出される場所です。

        notify_func = getattr(listener, 'on_%s' % frame_type)
        notify_func(headers, body)

これはメソッドにあります__notify（639行目で宣言されています）：

def __notify(self, frame_type, headers=None, body=None):

これらは、try ブロックにない場合です。

  • 331（connectedイベント用）
  • sendイベントは426
  • 743disconnected

しかし、messageが呼び出されるのは 727 行目です。

# line 719
try:
    # ....
    self.__notify(frame_type, headers, body)
于 2013-03-06T14:58:26.467 に答える
0

最後に、名前でロガーを取得し、それにStreamHandlerを設定しました。

import logging

log = logging.getLogger('stomp.py')
strh = logging.StreamHandler()
strh.setLevel(logging.ERROR)
log.addHandler(strh);
于 2013-03-06T20:43:46.717 に答える