The compile() methods for each language statement have now been reviewed, and constant error message text removed and relocated to a localizable message element.
So some messages used to be generated including literal strings like “missing comma”, but now generates a SYNEXPTOK message, indicating what the expected token was.
Along the way, I’m starting to use nested error messages, such as the one above. The primary error is INPUT, indicating an error on the INPUT statement. It’s parameter is a nested error message, SYNEXPTOK, telling about the specific error message.
There’s room for improvement in how these messages are formatted, but I like this structure of generic/specific messaging; it makes it easier to write handlers for the general messages, which may make decisions based on more specific details. I’m going to start using this more in the runtime error handling, which is the next string literal cleanup project on my plate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The compile() methods for each language statement have now been reviewed, and constant error message text removed and relocated to a localizable message element.
So some messages used to be generated including literal strings like “missing comma”, but now generates a SYNEXPTOK message, indicating what the expected token was.
Along the way, I’m starting to use nested error messages, such as the one above. The primary error is INPUT, indicating an error on the INPUT statement. It’s parameter is a nested error message, SYNEXPTOK, telling about the specific error message.
There’s room for improvement in how these messages are formatted, but I like this structure of generic/specific messaging; it makes it easier to write handlers for the general messages, which may make decisions based on more specific details. I’m going to start using this more in the runtime error handling, which is the next string literal cleanup project on my plate.