It might be unusual but it is valid - I think we should track normal/
abnormal completion like Raymond suggested.
--
Jeremy
On Sep 8, 2006, at 8:11 PM, Jim Marino wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]