I don't think there is any valid application scenario for this even
if it is technically legal in Java. I would prefer we stick with our
original decision not to support this as anyone doing this in their
application code needs to redesign it anyway. Is there an example of
good design for application code that does this?
Jim
On Sep 8, 2006, at 11:34 PM, Jeremy Boynes wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
