Cyrille Giquello wrote: > >> > _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 ...
Any links where to download such a nice little tool? Marcel > > > cyrille > > >
