-
1. Re: Propagation of exceptions to client
timfox Jul 20, 2006 11:57 AM (in response to timfox)In the previous mail, please read "...and rethrow a JMSException that does not contain the original *exception*..."
-
2. Re: Propagation of exceptions to client
ovidiu.feodorov Jul 20, 2006 7:05 PM (in response to timfox)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? -
3. Re: Propagation of exceptions to client
timfox Jul 21, 2006 2:57 AM (in response to timfox)"ovidiu.feodorov@jboss.com" wrote:
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. -
4. Re: Propagation of exceptions to client
timfox Jul 21, 2006 3:01 AM (in response to 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. -
5. Re: Propagation of exceptions to client
timfox Jul 21, 2006 3:15 AM (in response to 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. -
6. Re: Propagation of exceptions to client
ovidiu.feodorov Jul 21, 2006 3:30 PM (in response to timfox)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. -
7. Re: Propagation of exceptions to client
starksm64 Jul 22, 2006 10:37 AM (in response to timfox)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; }
-
8. Re: Propagation of exceptions to client
timfox Jul 22, 2006 11:29 AM (in response to 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. -
9. Re: Propagation of exceptions to client
starksm64 Jul 22, 2006 11:53 AM (in response to timfox)I would only do that under trace level logging.
-
10. Re: Propagation of exceptions to client
igarashit Jul 26, 2006 6:52 AM (in response to timfox)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:) -
11. Re: Propagation of exceptions to client
joellindheimer Jul 26, 2006 11:12 AM (in response to timfox)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 -
12. Re: Propagation of exceptions to client
timfox Jul 26, 2006 1:12 PM (in response to 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. -
13. Re: Propagation of exceptions to client
timfox Jul 26, 2006 1:15 PM (in response to 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.