Details

    • Estimated Difficulty:
      Medium

      Description

      <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

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  dmlloyd David Lloyd
                  Reporter:
                  dmlloyd David Lloyd
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: