Friendly error handling
maetl opened this issue · comments
This has never really been prioritised as much as it should have been, but I have left some affordances in the internals—mostly around refactoring towards centralised lookups in the registry—to manage it better in future.
The main focus of the error messages should be to provide succinct and precise information about where the error occurred and what can be done to fix it.
Most of the time, this is going to be related to the generator attempting to expand a symbol that doesn’t exist in the grammar, so I think I want to put most of the effort into raising a specifically designed exception (with a well written message) for this particular use case.
Finally—after more than a year—I got around to addressing this in 0.15.
Rule symbols that expand to a missing rule now trace the line number of where the rule was defined.
- In the Ruby DSL, this means reporting the name of the symbol and the exact line number and string referencing the missing symbol.
- With passed in context rules, this means reporting the line where the bad rules were passed as an arg to
generateorevaluate. - In external file formats, this means tracing back as best as possible to the line in the original file where the bad rule was specified.
This isn’t perfect, and has meant some broad changes to the internals which could be much improved. But the quality of the error reporting has increased substantially. It’s far less annoying and confusing to track down bugs in a grammar now. You can actually see the exact rule that is causing the problem via the exception message, rather than an incomprehensible stack trace with no direct relationship to the grammar rules.
Happy to close this now, as the overall objective has been addressed.