I'm overhauling my semantic error handling in general. Right now, every error just throws an exception, but if I want to implement nice error handling in an environment, then it's going to have to be more intelligent than that. I think that right now, I'm going to classify errors into three or four kinds.
I have "Fuck, this operation failed" errors. These errors basically imply that the user attempted to do something they should not *and* that this affects the immediate semantic meaning of this operation- for example, an expression that tries to access a nonexistent member. You can't calculate the semantic properties of this expression in this circumstance. My current intention is that I will throw them as exceptions and catch them at AST analysis points. These points already support incremental re-analysis and such things so extending them to handle this situation would not be severely problematic.
I will also have "This operation failed, but not in a way that immediately affects analysis outcome". A simple example would be a function that is exported as an incompatible signature. When this occurs then it's obviously impossible for code generation to occur but I could continue analysing any use of that function as if there was no error. So far I basically intend to just make a note of each one and then I need to somehow "tie" it to the originating condition.
Thirdly, I'm thinking about configuration errors. For example, right now I have an error where if you try to index an array, we throw an exception if it's out of bounds, but generating this depends on typeid() which depends on <typeinfo> headers. So if the typeinfo headers aren't found, this is the compiler being plain misconfigured.
Finally, we have our good old friend Internal Compiler Error. This would effectively be a bug in the analyzer. Currently I have various assertions scattered throughout the code but at least a few of these could be refactored as ICEs.
