Re: [xmlblaster] Exception handling

[Marcel Ruff <ruff at swand.lake.de>]

Ben Cox wrote:

> Hello,
>  As impressive as XmlBlaster is, I have been trying to use it for a
> while now, and have come across this problem in a few different
> contexts.  My problem is that the exception handling in the system is
> _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!
>  For example, in sending a point-to-point message to a user who is not
> logged in, I receive the following XMLBlasterException:
>
> id=PtP.Failed reason=Sending PtP message to 'Joe' failed, message is
> lost. Client is not logged in and <destination forceQueuing='true'> is
> not set
>    at
> org.xmlBlaster.client.protocol.corba.CorbaConnection.publish(CorbaConnection.java:635)
>
>    at
> org.xmlBlaster.client.protocol.XmlBlasterConnection.publish(XmlBlasterConnection.java:1505)
>
>    at com.mc123.blaster.TestXMLBlaster.publish(TestXMLBlaster.java:99)
>    at
> com.mc123.blaster.TestXMLBlaster.sendTestMessages(TestXMLBlaster.java:143)
>
>    at com.mc123.blaster.TestXMLBlaster.<init>(TestXMLBlaster.java:38)
>    at com.mc123.blaster.TestXMLBlaster.main(TestXMLBlaster.java:202)
>
>  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.  You have a ConnectionException as a possible constructor
> argument to the XmlBlasterException, but I can't get to it from the
> XmlBlasterException!  Am I expected to parse the id String in order to
> have the code figure out what's going on?  But this could be any of a
> wide variety of values, depending upon the parameters passed into the
> client's command line, such as "CorbaConnection-guest",
> "SocketConnection", "RmiConnection-guest", etc., not to mention the
> array of possible non-connection things that can go wrong.  Where is
> the comprehensive list of id Strings?
>  Even if I do parse the id String, I still can't really know the
> specifics of what's going on without parsing the reason String, too.
> For my system  I need to be able to include the client in a GUI
> program, and pop up the program's configuration panel with the
> appropriate field highlighted, and a dialog saying something like:
> "Please verify that your server settings are correct.  If you continue
> to experience difficulty, call us at blah blah".  Without being able
> to get at a more specific exception, I can't figure out what to ask
> the user to reconfigure in the event that something goes wrong
> attempting to publish messages, etc.
>  How do you folks get around this in your own applications?  Do you
> parse the id String, and/or the reason?  Where do you keep the list of
> possibilities, or do I have to read through the source code every time
> I call a method?  Parse the logs?  No way!
>  Why didn't you create specific subclasses of XmlBlasterException,
> like most Java packages do?  And, if you needed polymorphism for
> Exceptions that are raised from code that you didn't write, couldn't
> you have stuck the raised Exception into an accessible field on the
> XmlBlasterException class (much like java.rmi.RemoteException and it's
> public Throwable detail)? This is really causing me some problems, and
> some doubts: because the learning curve on XmlBlaster has been so
> steep, I've had to invest quite a bit of time and energy into figuring
> out how to use it, which leaves me shocked to discover that it doesn't
> seem at all suited to building clients with any real exception
> handling (exception logging != exception handling).
>  Thanks for any light you can shed,
>
>    Ben

Hi Ben,

thanks for starting this discussion, it is overdue and time to clean up
the exception stuff.

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?

thanks

Marcel