Re: [morph-developer] Patch (ContainerCopier bug fix + TransformationException changes)

[Matt S. <Mat...@wh...>]

Thanks for the detailed explanations.  I am leaning towards accepting 
the patches but I would like to sleep on it.

One situation I was considering is if you are doing something simple 
like Morph.convertToInteger("13asdf") you want a TransformationException 
instead of a JDK  NumberFormatException.  This would be in the interest 
of hiding implementation details of a particular transformer from a 
user.  Fortunately, it appears the transformers happen to be written 
such that this is exactly what happens even with your change.  Of course 
I will need to do testing to verify this is the case.

I also like the idea of "if it's a Morph error, throw a Morph exception, 
otherwise rethrow the exception that actually occurred".  When I first 
started really using Morph that was one of the things that confused me 
too, even though I wrote the framework: I would see MorphExceptions and 
think it was a bug in Morph when in reality the issue lied elsewhere.

Matt

Ben Alex wrote:
> Alan Stewart wrote:
>   
>> We're using Morph now at Woolworths as the "Assembler" implementation in 
>> ROO to transform between rich domain object and DTO. If I have to catch 
>> a TransformationException (that wraps our business exception) in an MVC 
>> controller, it means we're tied to that implementation. If for what ever 
>> reason we swapped Dozer or a different implementation back in as the 
>> Assembler, then the controllers break.  I believe architecturally it 
>> would be more pure not to have the Morph exceptions in  client code.
>>     
>
> Hi Matt and Alan
>
> Pros of keeping TransformationException wrapping RuntimeExceptions:
>
> * Can determine Morph called the method which caused the exception.
> Mitigating factors: (i) introspect the stack trace and find it out that
> way; (ii) not a common requirement in my experience to know this anyway.
>
> Cons of keeping TransformationException wrapping RuntimeExceptions:
>
> * Morph leaks out beyond the assembly layer, as you are *forced* to
> catch a Morph-specific exception type in order to extract the nested
> RuntimeException. Mitigating factor: at least you can put such code into
> a static method.
>
> * Try...Catch blocks become more lengthy and complex, as they need to
> handle the TransformationException in a special manner (either directly
> or via a static method).
>
> * Becomes harder to debug and figure out what is happening. Having the
> untouched RuntimeException propagate through the control flow is the
> simplest solution. This means less user support from people unable to
> figure out what went wrong and are incorrectly attributing failure to
> Morph or trying to adjust configuration settings to fix what on the
> surface appears like a "Morph related problem". Less community support
> will be necessary if TransformationExceptions don't wrap
> RuntimeException, especially given general moves to RuntimeExceptions
> means a good number of users will be employing them anyway (and those
> employing checked exceptions will reasonably expect to have to deal with
> a nested exception - a side-effect of their checked exception choice).
>
> * Correct me if I am wrong, but Dozer doesn't force you to deal with its
> own exception hierarchy. Alan can confirm this, but I'm 99% sure. So on
> a competitive level, it seems desirable to follow the lead of the bigger
> project if users are ever expected to easily transition from Dozer.
>
> I may have missed something. Look forward to your thoughts.
>
> Cheers
> Ben
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> morph-developer mailing list
> mor...@li...
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>