Error Handling is Not Flexible

[eparis]

The *OnError mechanism for how to handle errors is insufficient. We now have #160 which wants to ignore unknowns. Using the current error handling options we would need to add IgnoreUnknown to all of the existing OnError types (aka we would need ContinueIgnoreUnknownOnError, ExitIgnoreUnknownOnError, PanicIgnoreUnknonwOnError, etc. Every new 'option' we want to have on Errors will double the number of defines. This is not the best API design.

[moorereason]

For the record, the *OnError design is inherited from the stdlib.

[rajatjindal]

Hi @eparis

How about keeping onerror same and adding ability to whitelist some errors

Something like

‘’’
type ParseErrorWhitelist struct {
Unknownflag bool
Someother bool
}
‘’’

And then we can whitelist for specific errors in parse functions

[tomasaschan]

This issue has not been updated in a long time. Is it still relevant?

(If I receive no answer before the end of the summer, I'll close it. Feel free to re-open if you come here after that happens and it is relevant to you - but if you do, please also comment and specify what outcome you're interested in!)