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
