Should reverse verification throw an exception?

[ajoz]

We are currently checking the rule sgn(a.compareTo(b)) == -sgn(b.compareTo(a)) but not handling any exceptions coming out of the a.compareTo(b) and b.compareTo(a) in any way. The question is should we handle this in any way?

Quoting the Comparable documentation:

The implementor must ensure sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) for all x and y. (This implies that x.compareTo(y) must throw an exception iff y.compareTo(x) throws an exception.)

I guess this means that would need to rewrite the verifyReverse method to handle such case. This also brings a question should this check be eligible for suppression? I am more inclined to

• if both sides x.compareTo(y) and y.compareTo(x) throw an exception than it is ok
• warn about compareTo throwing an exception even if it is symmetric
• if only one side throws an exception then throw an AssertionError to communicate this

If we would introduce the concept of a warning to the library then we could have treatWarningsAsErrors option, but this needs further discussion if we have enough "warnings" to justify such option. Also we should not work on it before we have both verifiers ready.

What do you think about it? @AlexZhukovich

[AlexZhukovich]

I think it's a great idea to support handling Exceptions because it's part of the language and we should handle them