feature request - add an error sub-type field for more precise error checking

[jmccormick2001]

feature request...

if a user of this api wanted to specifically check a CSV for 'example annotations' it would be
nice to have a predefined sub-type for that specific validation check...

for example:

if err.Type == errors.CSVFileNotValid && err.SubType == errors.ExampleAnnotationsNotFound {
}

[estroz]

This is a somewhat complex feature to implement because errors.Error contains a predefined set of error types, to which we would have to add types for each field being validated, for all manifest types this library validates (ex. errors.ExampleAnnotationsNotFound for ClusterServiceVersions). That isn't a scalable approach.

However I agree we need to have some way to either check error types for field values or subdivide validators further.

/cc @njhale @kevinrizza

[joelanford]

If we go down this path, would using Go 1.13's support for error wrapping and using errors.As() and/or errors.Is() help us?

[camilamacedo86]

I think we can close this one as outdated.
See that if the annotation not be informed we ignore it.
Also, we added the check: #207 you can see an example of this called in SDK operator-framework/operator-sdk#5495.

@exdx @dinhxuanvu WDYT?

[exdx]

This is somewhat outdated specifically in regards to the annotation validation, considering the linked PR where validation was done to ensure the annotation is valid JSON. More so, as we move away from the CSV and moving the related annotations into a properties.yaml file this type of check would be less useful.

More broadly, the ask for more defined errors is useful though. Not sure if we should close just yet.

[github-actions]

Issues go stale after 90 days of inactivity. If there is no further activity, the issue will be closed in another 30 days.