Originally we decided against this, as returning exceptions like this
is really bad coding convention and I can't think of any case where
it is valid in *application* code. I'm beginning to get worried about
the size of messages and the invocation stack in the runtime as our
memory footprint is expanding. I'd prefer we not do this as we need
to be mindful the majority of wiring is going to be local, in-shared-
memory services and we need to optimize for that. We can document
that application code should not return exceptions as part of the
message signature.
Jim
On Sep 8, 2006, at 5:14 PM, Raymond Feng wrote:
Hi,
I notice that we use the message body to flow business exceptions
back to the client with the following code from TargetInvoker
implementations.
public Message invoke(Message msg) throws InvocationRuntimeException {
try {
Object resp = invokeTarget(msg.getBody());
msg.setBody(resp);
} catch (InvocationTargetException e) {
msg.setBody(e.getCause());
} catch (Throwable e) {
msg.setBody(e);
}
return msg;
}
I think it's problematic. Even though most of the services won't
use Throwable as normal input/output but at least java syntax
allows so. Can we have a flag on the message to indicate it's a fault?
Thanks,
Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
