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