On Sunday 15 January 2006 10:59, rubicant rubicant wrote: > I'm trying to suggest that GCC should have error codes to describe > errors, continue reading on if you like the idea or not ;-) > > THE IDEA: > The idea is to make GCC better when it comes to error reporting. This > will be done using so called error codes which then can be looked up > in a properly > formatted document to see what the error means when in confusion. This > will save time when it comes to searching what a error means around > and improve usability.
FWIW, W3C have in the XQuery & XPath/XSL-T 2.0 set of languages used error codes. See for example: http://www.w3.org/2005/xqt-errors I, as user and implementor of the languages, have found it practical with error codes. It gives a clear indication of what is being reported(which can be difficult to tell when translated, for example), and a good way of backtracking into the compiler/engine. The XQuery Test Suite verifies that proper error codes are reported. At some stage it was decided to pad error codes so that they were equal in legnth(string wise). I don't know why, but perhaps it can be useful to know. >From an implementor's perspective it could be good to keep the error codes & related data in one place, and generate everything from that. For example, in my XPath/XQuery implementation I generate[1] an enumerator for the error codes as well as documentation for it, from the specification. In this way the error code are always in sync, and, most of all, the compiler's type checking verifies that valid error codes are used(which is not possible when strings are used, for example). It's a cheap way of finding invalid codes. FWIW, Frans 1. For example, see: http://websvn.kde.org/branches/work/kdom/xpath/environment/ReportContext.h?rev=496093&view=markup
