Simon, Right, though I just wanted to clarify my proposal involved treating checked and unchecked exceptions differently.
I like the idea of handling the checked exception with a wireFormat-specific means (e.g. for object WF just serialize the exc into an ObjectMessage and for dflt text/xml only serialize the fault obtained from the exception per JAX-WS like we do for <binding.ws>). For the unchecked exceptions, I just threw out there the idea that we construct a java.lang.RuntimeException and send back an ObjectMessage.... in all cases. An alternative would be to come up with an equivalent representation of RuntimeException for each wireFormat. The latter would seem to be more in the spirit of defining specific wireFormats for specific services. My suggestion has the advantage of there being less to document (and maybe less to code) to explain how this all works. Not sure... Scott On Fri, Feb 13, 2009 at 12:06 PM, Simon Laws <simonsl...@googlemail.com>wrote: > >> >> Without a spec, I can't think of a better thing to do for now for throwing >> unchecked exceptions over a <binding.jms> service >> than to always use an ObjectMessage, but I think we should do it in a way >> such that we don't require any SCA or Tuscany code on the client. > > > At the moment the chosen wireFormat has a bearing on the format of the > exception as it's thrown across the (JMS) wire. So in the default/textXML > case the exception is passed back over the wire as an XML document. With > Ant's latest changes it's arguably better than it was before. We pass back a > Text message with the exception XML in it. Intead of a Object message with > and Axiom object in it. > > In the case of Object format you would expect the exception to be in an > Object message. If you get into more esoteric wire formats I guess you have > to document how exceptions will be passed so that you can pick them up in > the non-SCA case. > > The alternative is to always throw exceptions in the same format. > > >> >> >> To do this, we're going to have to accept that we're going to accept that >> we'll lose the chain of exceptions we may have in the service-side container >> and simply throw a new java.lang.RuntimeException (and not >> ServiceRuntimeException), possibly reusing a chained exception's "message" >> (or maybe not even). >> >> So the non-SCA programming model for dealing with this becomes: >> // listen for a response >> if (responseMsg is ObjectMessage) >> look for RuntimeException in message and deal with this somehow >> else >> handle normally the message of=f expected message type (depending on >> wireFormat) > > > We would need to look inside the return message to see what is in there as > it might or might not be an exception. > > >> >> >> And for an SCA reference we would have to do the same for every wireFormat >> on the reference side, (and "dealing with" the RuntimeExc >> would translate into throwing ServiceRuntimeException). >> >> Thoughts? >> >> >> >
