#59 RuntimeExceptions should not be wrapped in MappingException

closed
None
5
2006-10-16
2006-09-20
Peter Monks
No

RuntimeExceptions thrown from custom code called by
Dozer during mapping (eg. custom converters) should not
be wrapped with MappingException, since it makes it
difficult to differentiate different types of mapping
error from outside the call to MapperIF.map.

My use case is a custom converter that throws a variety
of different exceptions (all sub-classes of
RuntimeException) and I need to be able to respond to
each type of exception differently. Because all of my
exceptions get wrapped in a MappingException I'm forced
to catch all MappingExceptions (even the ones I'm not
interested in), "unwrap" it to get the underlying
exception type and then execute a bluddy great if /
then / else statement for each different type. It
would more elegant to be able to use Java's native
support for multiple catch clauses instead.

It may even make sense to change MapperIF.map to throw
java.lang.Exception so that checked exceptions don't
have to be wrapped either.

Cheers,
Peter

Discussion

  • Matt Tierney

    Matt Tierney - 2006-09-26
    • assigned_to: nobody --> mhtierney
     
  • Matt Tierney

    Matt Tierney - 2006-09-27
    • status: open --> pending
     
  • Matt Tierney

    Matt Tierney - 2006-09-27

    Logged In: YES
    user_id=1236069

    I have made the changes to the 2.4 code base. I only
    tackled RuntimeExceptions, so checked exceptions will
    still get wrapped in a MappingException. But any
    RuntimeExceptions will get passed out of the Mapper
    without getting wrapped in a MappingException. With
    something as generic as an object mapper, I think it will
    be tough for a client to recover from any exception
    (checked or runtime) thrown from the mapper. But passing
    the RuntimeEx straight out will wrapping will provide a
    bit more flexibility and will make the the exception a
    little more readable. One use case I can think of that
    will benefit from not wrapping runtime exceptions is when
    you are mapping a DTO that is lazy loaded. If you need,
    you will be able to handle the LazyInitializationException
    w/o digging into the MappingException. Thanks for the
    feature post.

     
  • Peter Monks

    Peter Monks - 2006-09-29
    • status: pending --> open
     
  • Peter Monks

    Peter Monks - 2006-09-29

    Logged In: YES
    user_id=7747

    G'day,

    That works for me - the comment about not wrapping checked
    exceptions was more of a thought experiment than an actual
    need on my part.

    And while I agree about the difficulties of recovering from
    exceptions, there are cases where a developer needs to catch
    exceptions for reasons other than recovery. For example I'm
    catching the various different types of exception and
    converting each one to an equivalent SOAP Fault.

    Cheers,
    Peter

     
  • Matt Tierney

    Matt Tierney - 2006-10-02

    Logged In: YES
    user_id=1236069

    putting back to pending status

     
  • Matt Tierney

    Matt Tierney - 2006-10-02
    • status: open --> pending
     
  • Matt Tierney

    Matt Tierney - 2006-10-16
    • 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