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 は、 ゼロ除算と除算オーバーフローを区別しようとしません。 これは、
どの除算も時間が掛かる処理だからです。