In ROP, we only get CayenneRuntimeExceptions (CRE) returned to the
client. This hides much of the cause of the original problem from a
user debugging problems at the client end since the stack trace of
the original exception is lost and all you get are the details of the
CRE itself thrown by BaseRemoteService at around line 175.
I need to improve upon my recent commit in order to properly deal
with non-serializable exceptions. Andrus has alerted me to the fact
that there are exceptions out there (such as one in Derby) which
implement Serializable but which have fields which are not serializable.
(after all, what's the point in implementing serializable if it
isn't?), however perhaps we should be tolerant of this type of problem.
It looks like Hessian 3.1.2 will work around the problem and be able
to gracefully handle this situation. However Hessian isn't the only
possible transport Cayenne might use.
Our options appear to be:
1. It isn't our problem. The bug in Derby is going away and Hessian
is working around it too. Leave it as it is and put some notes in the
docs for people who don't use Hessian. The nice thing is that we can
get real exception data onto the client which can be very useful.
2. Add the original exception's stack trace to the CRE message.
Simple to do, but slightly ugly in that it fills up the previously
concise message with stack trace. Some users may expect their message
to be short and sweet.
3. Add new fields to CRE which are guaranteed to serialise (such as
String causedByStackTrace and causedByClassName) which can contain
this information. But then it is a bit more effort to get them out on
the client (say within log4j).
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A