Exceptions should uniquely identify the target resource

[wmrutten]

Exceptions thrown by the API while processing a resource (e.g. during de-serialization) should include (custom) properties that indicate the actual target resource, e.g. filename/url, resource id and/or canonical url.

This is particularly important in case of nested/recursive operations on multiple artifacts, e.g. when generating a snapshot of a profile with external dependencies.

Currently, there is no way for end users to determine the actual target resource of an error.

We may have to implement some custom derived exceptions, as runtime exceptions such as FormatException don't provide such identification properties out-of-the-box.

[ewoutkramer]

The parsers have no notion of files, as they read from Stream and string - so that means the caller has to provide these details. The current parsers only implement IAnnotated, not IAnnotatable - maybe we could provide support for IAnnotable so you can set this information on the root. Since the errors do give you back a reference to the faulting parser node, you could ask that node for these Annotations.

[mmsmits]

Should be solved in the code invoking the parsers, this needs to be solved on a case by case basis as we encounter them.

[ewoutkramer]

It's weird to pass context into the parsers, which they will then need to report out. Better that the caller (say a Resolver) adds that context when it catches a parse error. Currently, the resolvers can only return null, so this kind of exceptions is "swallowed". That's the real problem, not the fact that there is no context in the parse exceptions.