+1 I like the idea of being able to identify some part of the error (origin, criticality, etc.) without having to open an external table with error description and lookup the error number in that table.
That said, the various ranges need to be selected carefully in order to allow the addition of new errors , and the numbering scheme must be clearly defined and documented on the website (and maintained up-to-date). Regards, Pierre-Arnaud On 17 mars 2010, at 12:24, Emmanuel Lecharny wrote: > Hi guys, > > Felix has done a tremendous work extracting all the error messages from the > code and gathering them in a sub project (shared-i18n and apacheds-i18n). > > This is just great, but I think we should go a bit further. If we want to add > a new error message, we have to add a new number at the end of the list. As > all the numbers start from 1 and are incremented, it becomes rapidly > difficult to group errors by their numbers (ie, all the errors between 450 > and 460 are related to operation X). > > What about defining a number which would inform immediately about the kind of > message we are dealing with ? We can for instance use hex numbers, where the > two higher bits will be used to indicate the log level : > DEBUG = 00XXXXXXXXX... > INFO = 01XXXXXXXXX... > WARN = 10XXXXXXXXX... > ERROR = 11XXXXXXXXX... > > The idea is that if the number is <0, then it's an error or a warning. > > IN the same vein, we can also split the errors by family. As the number will > be an integer, it remains 30 bits to store informations. Assuming that shared > messages are indicated by the bit number 29, then we have a way to split > again : > 101xxxxxx = a warning in the shared module > 1111xxxxx = an error in the shared module, asn1 subproject... > > etc. > > wdyt ? > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.nextury.com > >
