XQuery’s Error Codes

That XQuery and the second generations of XSL-T and XPath requires error codes to be reported generates opinions. And work for the working groups. However, I think it’s possible to discuss these error codes with nuance.

For the uninitiated(and shall we say, lucky?), this error code-feature is about requiring implementations to report specific error codes that identifies the faults. For example, a syntax error raise XPST0003 while a type error, like trying to substract an integer from a string, raise XPTY0004. And so on. The specifications summarize the error codes in the appendices, making story telling for your grand children a blast.

This error code feature surely receive different reactions, and perhaps they have shifted after seeing it being edited and implemented during XQuery’s development. Some members would like to nuke it. And obviously, the feature got in there in the first place.

Relatively late in the process of XQuery’s development there has been a number of editing done related to error codes. One such report was momentarily resolved with the comment:

The WGs agree that the spec is unclear in this area, but feel that this will always be true for some of our error behavior. Lacking a specific proposal for change, we agreed to close this bug report with no action.

Those who support error codes and think the specifications are vague have learned a lesson: apparently it’s not practically possible to specify it properly, so it shouldn’t have been there in the first place. One might think that it’s ok that the specification is vague in some areas, but I don’t. Afterall, error codes are normative requirements.

Not that I agree with the above quote. I’d rather say that the specifications has been vague. The reason people may think they are specified vague is that the dirt has been identified. But also fixed. So I’m a bit optimistic in that area, although one could perhaps say that one must have read the specifications to a pathehic degree to realize how the error codes doesn’t step on each other, and so on.

Why can one think error codes are good?

In Test Frameworks for W3C Technologies from 2002, Dimitris Dimitriadis writes:

More interesting effects can be reached using a more “intelligent” authoring mechanism. Fairly simple rules encoded in a DTD can be used so that authors write specifications in a more uniform manner. This DTD could be extended to include markup for test assertions that individual tests could then point back to.

I think the error codes have had the effect that the last sentence wants to achieve.

The testing task force has internally a stylesheet that extracts the error codes and matches them against the test suite in order to verify coverage. Without error codes, it would still be as much to test, it would just be impossible to programmatically verify the test suite in this area.

I think the same applies for those who read and implement the specifications. The error codes shine up like beacons for roads that should be walked. That’s the reason why editorial reports has been submitted: it is for readers identified what to read, and as they do, they stumble over the editorial issues.

In other words, when editorial reports have been dragging in the end it hasn’t been the error codes fault. It has been the issues they have helpt identify. Those hadn’t disappeared by letting error codes out, although possibly been left uncorrected.

So I think a significant advantage of error codes is how they have in different ways improve the quality of a specification, as Dimitris writes about.

For the more mainstream question regarding error codes — “are they sufficiently useful for users?” — I have no straight answer. Some like it, such as the GNU GCC people who recently have been bouncing patches for deploying error codes.

It is certain though that they require an effort when implementing. In Patternist, error codes has required explicit attention. Modularizations has been disjoint to the error codes to report, requiring designs to be extended to accomodate for these split models.

A great help has been to use a stylesheet to generate enums for the error codes. This has made it a piece of cake to stay in line with changes, and let the compiler check the correctness of codes(which is tricky at best when using strings, for example).