#2 mapping processor exception reorg

closed
None
5
2005-10-31
2005-10-20
Rohan Hart
No

Tiring of MappingException discarding my meaningful
exceptions (with help from InvocationTargetException)
the following patch centralises exception handling and
attempts to re-throw unchecked exceptions before wrapping.

Discussion

  • Franz Garsombke

    Franz Garsombke - 2005-10-21
    • assigned_to: nobody --> fgarsombke
     
  • Franz Garsombke

    Franz Garsombke - 2005-10-21

    Logged In: YES
    user_id=550744

    Wow...thanks for the contribution. I will check this over
    and put it in our 1.5.6 release.

    Thanks again.

    Franz

     
  • Franz Garsombke

    Franz Garsombke - 2005-10-21

    Logged In: YES
    user_id=550744

    Rohan -

    Not entirely sold on not wrapping unchecked exceptions.
    Frameworks like Spring do a similar thing in that they have
    one coarse grained runtime exception that developers can
    rely on if they care to catch a runtime exception, without
    having to catch the all-mighty Throwable. What information
    are you losing, besides not knowing that the runtime is a
    certain instance of something?

    Thoughts?

    Thanks,

    Franz

     
  • Rohan Hart

    Rohan Hart - 2005-10-22

    Logged In: YES
    user_id=774102

    The problem is that MappingException's idea of wrapping is
    to stringify the original exception (in order to support pre
    1.4 jdk). Unfortunately InvocationTargetException provides
    no details in that string as to what actually happened so
    validation errors or simple coding bugs all come back as a
    mapping exception caused by an exception during the
    reflective call.

    If you could support true exception wrapping in the 1.4+
    style I'd be just, or even more, happy.

    cheers
    Rohan

     
  • Franz Garsombke

    Franz Garsombke - 2005-10-22
    • status: open --> pending
     
  • Franz Garsombke

    Franz Garsombke - 2005-10-22

    Logged In: YES
    user_id=550744

    We will definitely put in the true exception wrapping...we
    did have that in the codebase until we backported to 1.3. I
    will put this in for the 1.5.6 release for next week.

    thanks,

    franz

     
  • Franz Garsombke

    Franz Garsombke - 2005-10-22

    Logged In: YES
    user_id=550744

    Adding this to the MappingException generates a much more
    detailed stacktrace. Is this sufficient?

    public class MappingException extends RuntimeException {

    private Throwable cause;

    public MappingException(String arg0) {
    super(arg0);
    }

    public MappingException(Throwable cause) {
    // For JDK 1.3 RuntimeException - it does not support a
    Throwable in the constructor
    super(cause.toString());
    this.cause = cause;
    }

    public Throwable getCause() {
    return cause;
    }
    }

     
  • Nobody/Anonymous

    Logged In: NO

    Yes, that would be sufficient.

    It might be nice not to wrap MappingException itself.

    cheers
    Rohan

     
  • Franz Garsombke

    Franz Garsombke - 2005-10-23

    Logged In: YES
    user_id=550744

    After thoroughly reviewing the exception handling I see your
    point about centralization. I have changed the exception
    handling extensively and am pretty sure it will meet your
    requirements. I basically took the concepts of centralizing
    everything but at the end of the day wrap in a
    MappingException...verifying that I haven't done any
    re-wrapping. Everything is checked into CVS if you want to
    take a look. Mostly changes in the MappingProcessor.

    Thanks

    Franz

     
  • Franz Garsombke

    Franz Garsombke - 2005-10-31
    • status: pending --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks