Propagation of exceptions to client

[timfox]

I'm wondering what our strategy should be for propagating server exceptions to clients.

If an exception occurs on the server side during an invocation of one of the methods on the JMS api, should we

a) Wrap it in a JMSException with the original exception as the rootcause in the jmsexception? Problem with this is the class of the original exception might not exist on the client side giving a ClassNotFoundException

b) Log the root cause on the server side, and rethrow a JMSException that does not contain the original message. (I lean towards this)

c) Something else?

Also how should we deal with RuntimeExceptions and Errors? Should we catch these too on the server side and rethrow JMSException?

[timfox]

In the previous mail, please read "...and rethrow a JMSException that does not contain the original *exception*..."

[ovidiu.feodorov]

Remoting wraps server-side exceptions and propagates them on the client. I found this quite useful while debugging.

Actually they use a neat trick that makes the exception stack trace look continuous, so you can see the error propagation path very clearly.

No matter how we do it, if something breaks on the server-side, the client stack trace should give a hint of what went wrong, not just "JMSEXception: something is wrong on the server".

The problem with a) can be solved by simply including the exception classes into the client jar. Why is this difficult?

[timfox]

The problem with a) can be solved by simply including the exception classes into the client jar. Why is this difficult?

See http://jira.jboss.com/jira/browse/JBMESSAGING-434 for example.

In this case the exception is thrown from the postgresql driver. Why should the client have to have all the jars in server/lib in their classpath just so they can see exceptions. That sucks IMO

I think we should log at the server and rethrow.

[timfox]

A related issue revolves around exceptions thrown from managed (JMX) methods.

Currently if an exception is thrown we have no record of it in the logs, and so don't know if anything happened. I think we need to catch and rethrow here too.

[timfox]

I don't think clients should be exposed to the implementation details of why the server failed.

The server admin people need to know this, but not the client. The client needs to to know something went wrong (e.g. "failed to acknowledge"), but it's leaking implementation details when we tell them it's because of a nested com.acme.widget.WidgetException from line 760 of com.acme.widget.SnoopOnCustomersClass.class

Not only does this require them to have the jars on the client it means clients can start doing things like this:

try
{
 producer.send(message);
}
catch (JMSException e)
{
 Exception cause = e.getLinkedException();

 if (cause instanceof WidgetException)
 {
 // do something
 }
}

Now the client code is tightly coupled to server implementation details.

I don't think we should give clients rope, since some are sure to hang themselves with it.

[ovidiu.feodorov]

Tim wrote:

In this case the exception is thrown from the postgresql driver. Why should the client have to have all the jars in server/lib in their classpath just so they can see exceptions. That sucks IMO

It certainly does. This is not what I had in mind. I was suggesting to wrap the Messaging server-side exception and forward it to client to provide some sort of information about what happened. In this particular case, the client would receive an exception thrown by our persistence manager saying that there are are problems with the database. No need to send a postgres driver exception class over the wire. The messaging exception classes should be in the client-side messaging jar, no additional effort required here.

For more details, obviously the server administrator has to consult the logs, where the database exception must be logged.

[starksm64]

I think we should be marshalling the exception message without the type to ensure info is not throw away:

import java.io.StringWriter;
import java.io.PrintWriter;

 try
 {
 ...
 }
 catch(Throwable e)
 {
 StringWriter sw = new StringWriter(256);
 PrintWriter pw = new PrintWriter(sw);
 pw.println("Cause:");
 e.printStackTrace(pw);
 pw.close();
 String reason = sw.toString();
 JMSException ex = new JMSException(reason);
 throw ex;
 }

[timfox]

Sounds like a good approach.

Do you think we should log the Throwable too on the server side, so we have at least some record of something having gone wrong that the sysadmin can identify?

I know this can be a religious argument with good arguments against logging unless the exception is handled in some way.

[starksm64]

I would only do that under trace level logging.

[igarashit]

good idea, but someone may think that the server side exception
should not be shown at client, I think.
It is better that whether the string is transmitted to client or not is configurable.
And, I think it should be logged on the server side,
because of the trouble to solve is on the server side.

Hmm, do you understand me? sorry to my poor english:)

[joellindheimer]

Question about trace level logging:
I guess i don't understand why one would not log an 'unexpectected' Throwable with anything less than a warn level. Why would the serverside not be interested in knowing about such Exceptions, or have I misunderstood your comment?
JL

[timfox]

"igarashit" wrote:
good idea, but someone may think that the server side exception
should not be shown at client, I think.
It is better that whether the string is transmitted to client or not is configurable.
And, I think it should be logged on the server side,
because of the trouble to solve is on the server side.

Hmm, do you understand me? sorry to my poor english:)

I am inclined to agree. I don't think should be told what's wrong at the server - it's not of their concern. I think the client should only be told information that's going to help them in some way, e.g. if they have misused the API. Being told the database has crashed is not for them to know. This kind of thing should be logged out at the server side, where (for instance) log4j could be configured to shoot out an email to the sysadmin.

[timfox]

"joellindheimer" wrote:
Question about trace level logging:
I guess i don't understand why one would not log an 'unexpectected' Throwable with anything less than a warn level. Why would the serverside not be interested in knowing about such Exceptions, or have I misunderstood your comment?
JL

I see your point. This is the kind of information that sysadmin's need to know about with a production (non trace) configuration.