> > _way_ too generic... I can't figure out how to ascertain what went > > wrong programmatically at all. All I can ever seem to find out is > > that there was an XmlBlasterException! > > > > See, short of parsing the id String, it is quite difficult to > > ascertain what is going wrong in the system. Is it that the client is > > not logged in, or was it a connection problem? It's easy to tell when > > reading it, but I can't figure an easy way to find out from within the > > code.
> What i often thought to do is adding a real ID (error codes) to > XmlBlasterException. > I would still stick with only one Exception, namely the > XmlBlasterException, > otherwise every new exception type would brake the interface contract > between client and server. > > But having a list of documented IDs (error codes) is probably a good > approach, > similar to the > > HTTP error codes: > HTTP/1.1 400 Bad Request > HTTP/1.1 501 Method Not Implemented > ... > > or to the > > JDBC error 'SQLstate" string, which follows either the XOPEN SQLstate > conventions or the SQL 99 conventions' > > JMS uses the JMS Exception with some derived Exception types, > but as we are not Java only and with the above mentioned reasons, > i would probably prefer to stick with one exception only. > > Any comments? the argument that many langages use xmlBlaster make me prefer the numric ID Code error. a little dream : A html page & a xml file on xmlBlaster.org will contains all error codes , with, for each, a description translated in many langages. Not informatic langage, but human langage ;o) english, german, french, spanish ... Like a DTD or NameSpace for xml, a application can donwload the error code list to make localisation ... cyrille
