Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: 8 May 2003 21:39:28 -0000
Message-ID: <20030508213928.5471.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 19781] New:  -
    PropertyUtils.copyProperties throws exceptions contrary to documentation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19781>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19781

PropertyUtils.copyProperties throws exceptions contrary to documentation

           Summary: PropertyUtils.copyProperties throws exceptions contrary
                    to documentation
           Product: Commons
           Version: unspecified
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Bean Utilities
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: apacheBugzilla@AMammenT.cotse.net


1) The copyProperties method is documented as throwing IllegalAccessException 
when access to a particular method is not available.  In fact, because 
internally the methods to be invoked are filtered for accessiblity 
(MethodUtils.getAccessibleMethod) before invocation, the possible sources of 
the IllegalAccessException will never actually throw an 
IllegalAccessException.  

Worse, however, is that the result of a failure to return an accessible method 
is actually taken as occasion to throw a NoSuchMethodException instead.  

2) The copyProperties method is also documented as throwing 
NoSuchMethodException when a method cannot be found.  I'm not sure if this is 
an error or not, but a NoSuchMethodException is not thrown when a property of 
the same name but a different type is found.  (This would, to my mind, be an 
occasion of not finding an appropriate method for the setter to function 
properly).  

Unfortunately, again, there is something worse.  In this case, instead of 
throwing NoSuchMethodException, an IllegalArgumentException is thrown.  
IllegalArgumentException, as a runtime exception, might have been 
appropriateexcept for the fact that it is explicitly documented as being 
thrown when either the source or the destination arguments are null - no other 
reasons for throwing this are detailed.  (Wouldn't NullPointerException be 
more appropriate anyway? Curious about the decision to recast this to 
IllegalArgumentException....)  While this is certainly allowed for 
RuntimeExceptions, in this case, the documentation is quite misleading about 
what is actually to be expected.  

I'll attach a JUnitTestCase that captures both of these items.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org