7 Error messages

Gforth の典型的なエラー・メッセージは以下のようになります:

in file included from \evaluated string/:-1
in file included from ./yyy.fs:1
./xxx.fs:4: Invalid memory address
>>>bar<<<
Backtrace:
$400E664C @
$400E6664 foo

エラーを特定するメッセージは Invalid memory address です。 そのエラーはファイル ./xxx.fs の 4 行目をテキスト解釈(text-interpreting)しているときに発生しました。 その行のエラーが発生したワードを(>>> と <<< で囲んで)指摘します。

エラーを含むファイルは ./yyy.fs の 1 行目でインクルード(included)されており、 yyy.fs はファイル以外からインクルードされています(この場合、 yyy.fs を Gforth へのコマンドライン パラメータとして指定することにより)。

エラー・メッセージの最後には、 バックトレースとして解釈できるリターン・スタック・ダンプが表示されます(空の可能性があります)。 その一番上の行には throw が発生したときのリターン・スタックのTOSが表示され、 その一番下の行には最上位のテキスト・インタプリタのリターン・スタックのすぐ上にあるリターン・スタック・エントリが表示されます。

ほとんどのリターン・スタック・エントリの右側には、 そのリターン・スタック・エントリをリターン・アドレスとしてプッシュしたワードを推測して表示します。 これによりバックトレースが得られます。 この例では、 bar が foo を呼び出し、 foo が @ を呼び出していることがわかります(そして、 この @ には 「Invalid Memory address」例外がありました)。

注意: バックトレースは完璧では無いことに注意してください。 どのリターン・スタック・エントリがリターン・アドレスであるかは知りません(そのため、 誤検知が発生する可能性があります)。 また、 (abort" など、)場合によっては、 リターン・アドレスからはリターン・ アドレスをプッシュしたワードを特定できないため、 リターン・アドレスによってはリターン・スタック・ダンプに名前が表示されません。

リターン・スタック・ダンプは、 特定の throw が execute されたときのリターン・スタックを表します。 catch を使用するプログラムでは、 リターン・スタック・ダンプにどの throw を使用する必要があるかが必ずしも明確ではありません(たとえば、 エラーを示すある throw がキャッチされ、 そのリカバリ中に別のエラーが発生したとすると、 スタック・ダンプにはどの throw のを使用するべきでしょうか？)。 Gforth は、 最後に execute された(そして、 その execute からまだ返ってきていない状態で、 ) catch または nothrow の後の最初の throw のリターン・スタック・ダンプを表示します: 通常、 これはうまく機能します。 正しいバック・トレースを取得するためには、 通常、 エラーが再 throw されない場合は catch の後に nothrow または ['] false catch 2drop を挿入します。

gforth エンジン(訳注: OSコマンドラインから gforth で起動)は、 プリミティブが生成した throw のリターン・スタック・ダンプを行えます(例: invalid memory address(不正なメモリアクセス), stack empty(スタックが空) 等)。 gforth-fast エンジン(訳注: OSコマンドラインから gforth-fast で起動)は、 直接呼び出された throw (abort などを含む) からのリターン・スタック・ダンプのみを行うことができます。 gforth-fast エンジンのプリミティブによって例外が発生した場合、 通常はリターン・スタック・ダンプは全く見れません。 しかしながら、 catch によって例外がキャッチされ(たとえば、 何らかの状態を復元するため)、 その後再び throw が返される場合、 最初の throw に対するリターン・スタック・ダンプは見れます。

また、 gforth-fast は、 ゼロ除算と除算オーバーフローを区別しようとしません。 これは、 どの除算も時間が掛かる処理だからです。