commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 18835] - BeanComparator compare method throws ClassCastException regardless of underlying exception
Date Wed, 09 Apr 2003 03:27:34 GMT
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=18835>.
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=18835

BeanComparator compare method throws ClassCastException regardless of underlying exception





------- Additional Comments From tobrien@discursive.com  2003-04-09 03:27 -------
Comparator throwing ClassCastException is a strange design decision by Sun.  It 
would make more sense to throw an IllegalArgument (possibly), or even to create 
another NotComparableException, etc.  But.... in the interest of pragmatism, 
I'm not about to buck the trend - it makes sense to stick to the interface.  If 
an exception occurs which prevents comparison, a ClassCastException is now 
thrown.

If, on the other hand, any general Exception is thrown ... a RuntimeException 
is thrown and the exception message is appended to that exception's message.  

I agreed completely, that it would make more sense to use a 
NestedRuntimeException from commons-lang, but from what I see beanutils does 
not yet depend on lang, so I went with a RuntimeException for now.  beanutil 
depending on lang is another discussion that should probably happen on commons-
dev.

Also, it should be noted that comparator.compare is now outside of a try/catch, 
if a nested Comparator wants to throw a runtime exception, there's no reason to 
catch it in this compare method.  This also seems to be more in line with other 
comparators in Collections that wrap other comparators - NullComparator, 
ReverseComparator, etc.

I've attached both the entire class and a diff.  The reason I posted the entire 
class was for discussion purposes.  I described the changes in the previous 
comment - exception handling, more javadoc, and the ability to ignore a missing 
property.

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


Mime
View raw message