Re: Open issue: error codes

John Lumley <> writes:
> In finalising the EXPath.binary specification
> ( we chose to use alphabetic
> error codes, that were meaningful when read (though admittedly only in
> English - perhaps an oversight). But they were detailed and did give
> you information on why the error had been raised. If an implementation
> can give a user more detailed information about why an error occurred,
> then I think they really should..

Yes, that’s another direction we could go. But I have a couple of
reservations. The first is that we don’t have namespaces for error
codes, so the error codes wouldn’t have a lexical form that stands out.
You’d get things like:

  A mark must be one of @, ^ or -, (invalid-mark-character) and
  indicates whether the item so marked will be serialised as an…

I don’t think “invalid-mark-character” is as obviously an error code as
“s06”. And I’m not sure (error invalid-mark-character) is necessarly
going to be obviously a code either, especially to someone who isn’t a
native English speaker.

We could clarify that with more words, but Steven is already reluctant
to adopt error codes on the basis that he thinks they reduce the
aesthetics of the prose so I don’t think more words will help.

Second, we’d have to invent the error phrases. And we’d have to talk
about all of them. And we’d disagree about some of them. We have at most
7 more meetings before XML Prague. I don’t think the value of
English-language-like error codes over simple numeric codes is
sufficient to justify spending time now discussing what they might be.
No one who reads the spec is going to be unfamiliar with the idea of
error codes.

                                        Be seeing you,

Norm Tovey-Walsh

Received on Thursday, 21 April 2022 08:03:23 UTC