問題タブ [error-recovery]

私は長い間プログラミングをしてきましたが、プログラムがメモリ不足になると、クリーンアップして終了しようとします。つまり、正常に失敗します。実際に回復して正常に動作し続けようとしている人を最後に見たのはいつか思い出せません。

特にガベージ コレクション言語では、多くの処理がメモリを正常に割り当てることができることに依存しているため、メモリ不足エラーは回復不能として分類する必要があるようです。(回復不可能なエラーには、スタック オーバーフローなどが含まれます。)

それを回復可能なエラーにするための説得力のある議論は何ですか?

C ターゲットを使用する antlr で生成された Java パーサーがあり、非常にうまく機能します。問題は、エラーのあるコードを解析して、意味のある AST を生成することも望んでいることです。1 つのインポートで最小限の Java クラスをフィードすると、その後にセミコロンがありません。「インポート」トークンとインポートされたクラスのトークンが存在する 2 つの「ツリー エラー ノード」オブジェクトが生成されます。

ただし、次のコードを正しく解析し、このコードの正しいノードを生成するため、セミコロンを追加するか再同期してエラーから回復する必要があります。antlr が AST で内部的に生成するこの固定入力を反映させる方法はありますか? または、少なくとも「ツリーノードエラー」を生成したトークン/テキストを何らかの形で取得できますか?

C ターゲットの antlr3commontreeadaptor.cの 200 行付近にある次のフラグメントは、C ターゲットがこれまでダミー エラー ノードのみを作成していることを示しています。

ここで私は不運で、Java ターゲットが生成するエラー ノードだけがエラー ノードのテキストを取得できるのでしょうか?

今日、Rhino Securityをダウンロードして、いくつかのテストを開始しました。ただし、完全に分離して実行されるもののいくつかは、意図的に例外を発生させるものが実行された後、エラーが発生し始めます。そのテストは次のとおりです。

そして、失敗したテストとエラーメッセージは次のとおりです。

xunitの代わりにnunitを使用するようにコードを変更したので、ここでも問題の一部である可能性があります。

乾杯、
ベリール

これは、セッションをインスタンス化する基本クラスです

前文

エラー回復機能を備えた GLR パーサーを作成しました。エラーが発生すると、次の代替手段に分割されます。

1. 期待される要素を入力に挿入し (ユーザーが見逃した可能性があります)、通常どおりに処理を進めます。
2. エラーのある要素を予想される要素 (ユーザーがタイプミスした可能性があります) に置き換えて、通常どおり続行します。
3. エラーのある要素をスキップし、次の要素もエラーの場合は #2 に進みます。

しかし、入力に多くのエラーがある場合 (たとえば、ユーザーが誤って JPEG ファイルをパーサーに渡してしまった場合)、代替手段の数が指数関数的に増加します。

例

次の文法に対応するこのようなパーサー:

次のテキストに適用されます。

中程度の最新のデスクトップ コンピューターでは、「メモリ不足」で失敗します。

質問

入力エラーが発生した場合に選択肢の数を減らす方法は?

Sun (または Oracle) JDK パーサーで使用される解析およびエラー回復手法を知っている人はいますか? 私は特に、生成される高品質のエラー メッセージ (正確なエラーの場所 + 関連するステートメントおよび/または式、かなりきちんとしたもの) と、解析を続行する前に可能な限り少ないトークンをスキップする機能 (したがって、正しい構造を解析し、最も近い可能性のあるエラーを見逃さないでください)

というクラスを作成しましたLimitedInputStream。既存の入力ストリームをラップアラウンドして、そこから読み取られるバイト数を指定された長さに制限します。これは、次の代替手段として意図されています。

これには追加のバッファが必要です。

これはクラスです：

使用事例：

更新で起こりうる間違いなど、深刻なバグがないかクラスをコードレビューしてもらえますleftか？

これは理論的な問題のようです。

私が知る限り、ANTLR3 はその回復 (###) メソッドを使用してエラー自体を処理します。ANTLR3 がエラー回復に使用する方法を知りたいです。(つまり、パニックモード/フレーズレベルなど) 誰かがこれを理解するのを手伝ってくれますか?

私の最初の推測が正しければ、誰かがその回復メソッドの宣言を見せてくれればいいのですが。ありがとうございました。

このアプリケーション（c ++）では、LoadLibraryを使用してサードパーティのDLLをロードします。これらのDLLにより、「アクセス違反の読み取り場所0x00000000..」などの例外が発生することがあります。

たとえば、try＆catchまたはその他のメカニズムを使用して、このような例外から回復することは可能ですか？他の世界では、そのようなイベントに耐える同じプロセス内にサンドボックスを作成することは可能ですか？

ありがとうございました

エラー回復のメカニズムとして、文法規則で「エラー」を使用できることがわかりました。したがって、エラーが発生した場合、パーサーは現在の行を破棄し、次の行から解析を再開する必要があります。これを達成するための bison マニュアルの例は、次のようになります。

しかし、私はそれを使用できません。flex がスキャナーで '\n' を無視するようにしなければならなかったため、式が 1 行で表現されるように制限されなくなりました。式の終わりを示す特殊文字 (つまりセミコロン) がなく、「改行」トークンがない場合、エラーが発生したときにパーサーが次の行まで解析を続行するにはどうすればよいですか?

ありがとう..

そこで、ANTLR を使用して Java でコンパイラを作成していますが、コンパイラがエラーをどのように処理するかについて少し戸惑っています。

デフォルトの動作は、エラー メッセージを出力してから、トークンの挿入などによって、エラーから回復して解析を続行しようとするようです。原則としてこれが好きです。これは、(最良の場合) ユーザーが複数の構文エラーを犯した場合、エラーごとに 1 つのメッセージを受け取ることを意味しますが、次のエラーを検出するために再コンパイルを強制するのではなく、すべてのエラーについて言及します。私の目的には、デフォルトのエラーメッセージで問題ありません。すべてのトークンの読み取りが完了すると、問題が発生します。

もちろん、ANTLR のツリー コンストラクターを使用して抽象構文ツリーを構築しています。ユーザーがすべてのエラーを確認できるように、構文エラーが発生しても解析を続行するのは良いことですが、解析が完了したら、例外を取得するか、入力が構文的に有効でないことを示す何らかの兆候を取得したいと考えています。そうすれば、コンパイルを停止して、ユーザーに「申し訳ありませんが、構文エラーを修正してから再試行してください」と伝えることができます。私が望んでいないのは、ユーザーが言おうとしていたと思われる内容に基づいて不完全な AST を吐き出し、何か問題が発生したことを示すことなくコンパイルの次のフェーズに進むことです (エラーメッセージ以外)。コンソールに表示され、表示されません）。しかし、デフォルトでは、まさにそれを行います。

The Definitive ANTLR Referencemismatchは、構文エラーが検出されるとすぐに解析を停止する手法を提供します: メソッドとメソッドをオーバーライドしてsrecoverFromMismatchedSetをスローし、同じことを行うアクションをRecognitionException追加します。@rulecatchこれは解析エラーから回復する利点を失っているように見えますが、もっと重要なのは、部分的にしか機能しないことです。必要なトークンが欠落している場合 (たとえば、二項演算子の一方の側にしか式がない場合)、期待どおりに例外がスローされますが、余分なトークンが追加された場合、ANTLR はそこに属すると思われるトークンを挿入します。コンソール メッセージを除いて、構文エラーを示さない AST を生成し、陽気な方法で続行します。(さらに悪いことに、挿入されたトークンはEOFであったため、ファイルの残りの部分は解析されませんでした。)

たとえば、フィールドのようなものをパーサーに追加し、メソッドをオーバーライドしてアクションを追加することで、これを修正できると確信しています。これにより、isValid解析の最後にエラーが発生した場合に例外がスローされます。しかし、より良い方法はありますか？私がやろうとしていることは、ANTLR ユーザーの間では珍しいことだとは想像できません。