Open ericprud opened 7 years ago
The Promises Guide says to use the ECMAScript Error
type (or DOMException
), where the code is a string passed to the error, such as:
const oldPromise = windowA.Promise;
windowA.Promise = () => throw new Error("I break developer code, but not platform code!");
Not really necessary to make these URL-friendly. Of course, in the spec, there are URLs defined for each error for reference purpose, such as that for invalid schema.
In principle, a ShExErrorCode like "invalid schema" could be identified by http://www.w3.org/ns/shex#12345. It's a little easier on (English-speaking) people who are reading the error code directly (vs. having some interface sanitizing/localizing/contextualizing the results) if the text is property English strings. OTOH, it's easier on parsers (and adds some future-proofing) if there's a procedural mapping from error code to a URL.
Is this list considered extensible? May an implementation add error codes, e.g, "service not available", "query endpoint unreachable", "401 auth required"? Of should they use one of our error codes and stick their details in a new attribute?
The whitespace in
ShExErrorCode
makes the natural URL form require some transformation or encoding. Encoding would look likehttp://www.w3.org/ns/shex#invalid%20schema
.