-
Feature Request
-
Resolution: Done
-
Major
-
None
-
None
-
Medium
<galderz> dmlloyd, ping
<dmlloyd> galderz: pong
<galderz> dmlloyd, so, wrt providing more meaningful stacktraces, did you create a jira for it?
<dmlloyd> hm, no I don't think I did
<dmlloyd> I did have an idea though
<dmlloyd> I'm not sure how well it's going to work for unmarshalling
<dmlloyd> but for marshalling, we could create a special exception type which keeps a list of objects that are being marshalled (rather than a stack trace)
<dmlloyd> then we put this exception in the "cause" field of everything we throw
<galderz>
<dmlloyd> then each writeObject() has a try
catch (IOException e)
{ addObjectCause(e, obj) }<galderz> i like the idea
<dmlloyd> and a catch for RuntimeException, and for CCE, etc.
<dmlloyd> then addObjectCause just pulls the cause field, checks if it's our MarshallingException, and if so, adds the object to the list
<dmlloyd> gotta make sure that list is transient though otherwise marshalling the exception will re-trigger the exception
<galderz> that would help a lot in figuring what had been marshalled and at what point if failed
<dmlloyd> maybe add the toString() of the object, or better yet the class name + "@" + hash code
<dmlloyd> for unmarshalling it's tougher because you only get an object if unmarshalling is successful...
<galderz> toString() could be something that is got if trace is on
<galderz> i know, unmarshalling is the great pain
<galderz> regardless, this work would tight greatly with https://jira.jboss.org/jira/browse/ISPN-155
<dmlloyd> so in that case we'd have to sprinkle try/catches all over the unmarshalling code...
<galderz> for unmarshalling, the only thing u can do is show what you have unmarshalled so far
<dmlloyd> yeah but we don't want to incur any kind of performance overhead, so whatever we do must only be in the failure path
<galderz> absolutely
<galderz> otherwise u're keeping lists for nothing
<dmlloyd> I think if we add a try/catch anywhere we recurse, that might work...
<dmlloyd> so reading fields, calling user readObject methods, etc.
<dmlloyd> maybe it'd be a good idea to have a separate UnmarshallingException, since the objects won't be initialized yet
<dmlloyd> we could even have a fieldName field, which is filled in with the name of the field being unmarshalled (if any)
<dmlloyd> could probably overload getStackTrace to make the output more readable
- relates to
-
ISPN-155 Marshalling code to provide more helpful stacktraces
- Closed