Create standard error models for all thema operations

[sdboyer]

Create standard error models for all thema operations

[sdboyer]

This is gonna take some discussion before starting - probably needs a design doc.

[sdboyer]

Note that this:

Line-level information about errors

is deceptively tricky. On the one hand, CUE very awesomely carries line-level traceability for validation errors by construction. But there are caveats.

Line-level error info ultimately ties back to associations between the vertices that underlie a cue.Value and source file, specifically a token.Pos. There are many things that can cause a cue.Value to lack such information - e.g., if it was created by cue.Value.Unify(), if it is the result of a comprehension.

It's not as simple as "if cue.Value.Source() returns nil, there will be no line info in errors." That wouldn't simplify things much, anyway. But i do not know of a clean, general rule that clearly tells us in what circumstance we can expect errors coming from to have line information (a non-empty return from this). (cc @myitcv)

In addition to the pure CUE reasons that line numbers may be lacking, we'll also need to account for things the user may have done that would cause the cue.Value contained in a Thema type to have its line numbers disappear. For example, on Instance, Translate() Hydrate and Dehydrate all manipulate a cue.Value in a way that may make it impossible to meaningfully include line numbers in errors, as the source has undergone a transformation and the "input file" no longer exists. Similarly, composition (#8) will almost certainly include calls to cue.Value.Unify() that...could? cause similar issues.

When i decided Thema should accept cue.Value as the input type for various funcs like BindLineage() or Schema.Validate() (vs. say having them accept []byte), it significantly simplified Thema's API, but it came with the burden of dealing with some of these error ambiguities. As a result, we have to generally expect that every error Thema emits will have both a "with line number" and "without line numbers" form. A complete error model will need to account for this difference, perhaps including explicit differentiation between cases where there are no line numbers because an original input cue.Value lacked source context, and cases where Thema operations themselves have caused them to be unavailable. Ambiguity around error line number availability has been quite frustrating for me when working with the CUE API, and i suspect it will be just as frustrating for Thema's users.

That said, not all of this needs to be dealt with in a first pass. I'm just outlining the scope of the problem.