[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] Exception handling


> _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