When parsing, any token that goes unclaimed is bad, thus there should be a default case in the switch statement that handles this token. How bad this situation is depends on the circumstances. In development, I would prefer the parser to crash and burn so I could fix the problem right away. However, I would understand if this result was undesirable in production. Instead a logging framework like NLog could be used to record the unclaimed tokens.
I think the best solution would be to include the crash and burn code, as this introduces no dependencies. To compensate, the exhaustive flag in the template will be turned off by default.
When parsing, any token that goes unclaimed is bad, thus there should be a default case in the switch statement that handles this token. How bad this situation is depends on the circumstances. In development, I would prefer the parser to crash and burn so I could fix the problem right away. However, I would understand if this result was undesirable in production. Instead a logging framework like NLog could be used to record the unclaimed tokens.
I think the best solution would be to include the crash and burn code, as this introduces no dependencies. To compensate, the exhaustive flag in the template will be turned off by default.