Hi Greg Good questions. Had some discussion with Mike about this off-line. I'm sure he'll pitch in. My 2c.
On Wed, Aug 24, 2011 at 10:02 PM, Greg Dritschler <[email protected]> wrote: > I have a couple of questions about how to handle runtime exceptions from an > asynchronous service implementation. > 1) Can the service implementation use ResponseDispatch.sendFault() to send > ANY Throwable, or only one of the exceptions declared using @AsyncFault? If > the former, I think there may be some issues with representing the fault in > some databindings (e.g. JAXB), since there isn't a mapping for it. If the > latter, it means of course that an attempt to send something outside the > defined exceptions will fail, and the client won't get anything (but > presumbably will time out eventually). I would say no to ANY Throwable. In the real world with coarse grained services and reliable async services I wouldn't expect a client to have to deal with arbitrary exceptions from services. If the implementers want to return technical exceptions then I would expect the business interface to describe them. A Java implementation will likely have to deal explicitly with ServiceRuntimeException so I may grudgingly agree that ServiceRuntimeException should be supported in this respect. See my next comment. > 2) If the service implementation fails with a runtime exception prior to > invoking ResponseDispatch (either sendResponse() or sendFault()), is it > reasonable to return a ServiceRuntimeException to the client? > Greg Hmmm, more interesting. In this situation the exception throwing is less controlled. Let's assume the Throwable is returned to the implementation provider. In real scenarios I would still promote a view that the client is not expecting arbitrary exceptions. However to make this work would probably mean instigating reliability and suitable queues and logs so that manual intervention can resolve the situation at the service before retrying (or returning a business exception). Currently we don't have this infrastructure so what to do? We could either log to the console or return ServiceRuntimeException to the client (as you suggest). The latter seems most consistent for base support. This behaviour could then be overridden using suitable interceptors or implementation provider implementations in future, more reliable, versions of the runtime. regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
