2023/03/14
エラーの扱い
やったこと
- タイガーブック、型検査の実装
昨日の日報でエラーの扱いを書いたけど、実装してたら全然違うことに気づいた。
構文解析でも意味解析でもエラーを発見した時点でエラー内容を標準出力しておいて、回復不可能なエラーや致命的なエラーでは例外を投げて終了する。
エラーが発見された時点でエラー内容が出力されているため、エラーを表わすトークンや型には何も情報を持たせなくてよくて、エラー記号を発見した時も致命的な問題が無ければ無視して解析を進める。
また、変数や関数の宣言でのエラー記号をそのままエラー型で記号表に登録してしまうと、その呼び出し側で連鎖的に不都合が発生するため、宣言でのエラーは例外を投げる方が良いと思っていたけど、宣言でエラーがあるかつ本体で本来宣言されていたはずの記号を参照しないこともありえるし、宣言の右辺のみにエラーがある場合はユーザとしては自分で型や変数、関数をすでに宣言し終えているという気持ちになるため、宣言でのエラーも例外を投げない方が良いのかもしれない。
まとめると、初めてエラー型を使う (詰める) 時はエラー文を標準出力し、エラー型を参照したり呼び出したりする時はエラーを伝播させるのみにする。
実装していて気づいたことだけど、エラーが起きたトークンの位置などきちんと詳細なエラー報告をする場合、抽象構文の段階でトークン毎に位置情報を持たせなければいけない。
そりゃそうなんだけど、本の通りに実装していたら、ここまで細かくできない。
思ったこと
あんまり余裕が無い。 型検査の実装が時間かかる。 型検査以前のフェーズでの修正がたまに見つかることも原因なんだけど。
今日の英会話
アメリカで大学進学率が落ちている話。