Next: 再表示エラーのデバッグ, Up: Lispデバッガ [Contents][Index]
デバッガに入るタイミングとして一番重要なのは、Lispエラーが発生したときです。デバッガではエラーの直接原因を調査できます。
しかしデバッガへのエンターは、エラーによる通常の結末ではありません。多くのコマンドは不適切に呼び出されたときにLispエラーをシグナルするので、通常の編集の間にこれが発生するたびデバッガにエンターするのは、とても不便でしょう。したがってエラーの際にデバッガにエンターしたいなら、変数debug-on-errorに非nilをセットします(コマンドtoggle-debug-on-errorはこれを簡単に行う方法を提供する)。
再表示コードによって呼び出されたLispエラーは、技術的な理由によりこのサブセクションで定義されている機能ではデバッグできないことに注意してください。これらについてのヘルプについては再表示エラーのデバッグを参照してください。
この変数はエラーがシグナルされて、それがハンドルされていないときにデバッガを呼び出すかどうかを決定する。debug-on-errorがtなら、debug-ignored-errors(以下参照)にリストされているエラー以外の、すべての種類のエラーがデバッガを呼び出す。nilならデバッガを呼び出さない。
値にはエラー条件(エラーをシグナルする方法を参照)のリストも指定できる。その場合はこのリスト内のエラー条件だけによってデバッガが呼び出される(debug-ignored-errorsにもリストされているエラー条件は除外される)。たとえばdebug-on-errorをリスト(void-variable)にセットすると、値をもたない変数に関するエラーにたいしてのみデバッガが呼び出される。
eval-expression-debug-on-errorがこの変数をオーバーライドするケースがいくつかあることに注意(以下参照)。
この変数が非nilのとき、Emacsはプロセスフィルター関数と番兵(sentinel)の周囲にエラーハンドラーを作成しない。したがってこれらの関数内でのエラーは、デバッガを呼び出す。プロセスを参照のこと。
この変数はdebug-on-errorの値に関わらず、デバッガにエンターすべきでないエラーを指定する。変数の値はエラー条件のシンボルおよび/または正規表現のリスト。エラーがこれら条件シンボルのいずれか、またはエラーメッセージが正規表現のいずれかにマッチすれば、そのエラーはデバッガにエンターしない。
この変数の通常の値にはuser-error、および編集中に頻繁に発生するがLispプログラムのバグに起因することは稀であるような、いくつかのエラーが含まれる。しかし“稀である”ことは“絶対ない”ということではない。あなたのプログラムがこのリストにマッチするエラーによって機能しないなら、そのエラーをデバッグするためにこのリストの変更を試みるのもよいだろう。通常はdebug-ignored-errorsをnilにセットしておくのが、もっとも簡単な方法である。
この変数が非nil値(デフォルト)なら、コマンドeval-expressionの実行により一時的にdebug-on-errorがtがバインドされる。Evaluating Emacs Lisp Expressions in The GNU Emacs
Manualを参照のこと。
eval-expression-debug-on-errorがnilなら、eval-expressionの間もdebug-on-errorの値は変更されない。
condition-caseでキャッチされたエラー、は通常は決してデバッガを呼び出さない。condition-caseはデバッガがそのエラーをハンドルする前にエラーをハンドルする機会を得る。
debug-on-signalを非nil値に変更すると、condition-caseの存在如何に関わらずすべてのエラーにおいてデバッガが最初に機会を得る(デバッガを呼び出すためには依然としてそのエラーがdebug-on-errorとdebug-ignored-errorsで指定された条件を満たさなければならない)。
たとえばemacsclientの--evalオプションによるコードの評価からバックトレースを取得するためにはこの変数をセットすると便利。この変数が非nilのときにemacsclientで評価されたLispコードがエラーをシグナルすると、バックトレースは実行中のEmacsにポップアップされる。
警告:
この変数を非nilにセットすると、芳しくない効果があるかもしれない。Emacsのさまざまな部分で処理の通常の過程としてエラーがキャッチされており、そのエラーが発生したことに気づかないことさえあるかもしれない。condition-caseでラップされたコードをデバッグする必要があるなら、condition-case-unless-debug(see エラーを処理するコードの記述を参照)の使用を考慮されたい。
debug-on-eventをスペシャルイベント(スペシャルイベントを参照)にセットすると、Emacsはspecial-event-mapをバイパスしてこのイベントを受け取ると即座にデバッガへのエンターを試みる。現在のところサポートされる値は、シグナルSIGUSR1とSIGUSR2に対応する値のみ(これがデフォルト)。これはinhibit-quitがセットされていて、それ以外はEmacsが応答しない場合に有用かもしれない。
debug-on-messageに正規表現をセットした場合は、それにマッチするメッセージがエコーエリアに表示されると、Emacsはデバッガにエンターする。たとえばこれは特定のメッセージの原因を探すのに有用かもしれない。
‘*Backtrace*’バッファーのカレントスタックフレーム内のフォームはeコマンドで評価できる。またedebug中ならeやC-x
C-eのコマンドを使用すれば、同様のことを行うことができる。デフォルトではこれらのコマンドによってデバッガは抑制される(この時点でデバッガに(再)エンターすると、デバッグ中のコンテキストから抜け出してしまうので)。しかしdebug-allow-recursive-debugを非nil値にセットすると、これらのコマンドが再帰的にデバッガにエンターできるようになる。
initファイルロード中に発生したエラーをデバッグするには、オプション‘--debug-init’を使用する。これはinitファイルロードの間にdebug-on-errorをtにバインドして、通常はinitファイル内のエラーをキャッチするcondition-caseをバイパスする。