[
https://issues.apache.org/jira/browse/MATH-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15958103#comment-15958103
]
Bruno P. Kinoshita commented on MATH-1408:
------------------------------------------
Thanks for the pointer [~murkle]!
>IMHO the examples given by Bruno are programming errors that should be caught
>at compile-time.
Agree that would be better if they were caught at compile-time. However,
TreeMap provides the #get(Object) method from the Map interface contract. And
internally, it requires its keys to be comparables with the other keys. So even
a simple code like
{code}
TreeMap<String, String> treeMap = new TreeMap<String, String>();
treeMap.put("s1", "s2");
treeMap.get(1); //get(Object)
{code}
will compile fine, but you will get a runtime exception.
>A quick look at the Frequency class gives the impression that all the fiddling
>is to allow usage of int, Integer, long and Long as key of the same Frequency
>instance.
Yup. From what I understood from toying with the code, and reading parts of it,
the Frequency class simply helps you to keep track of things like cumulative
frequency, unique counts, etc.
The problem is that it uses the TreeMap as base structure, to create a
frequency table. So if you want to track the frequency over a series of
Integers, your Frequency object will still allow users to query for the
frequency of any Comparable<?>, instead of allowing only Integers. And then you
have to watch out for CCE runtime exceptions if the Comparable type is not
compatible with Integers.
> What is a use-case for Comparable<?> rather than Comparable<T> (i.e. have the
> class be a bona-fide generic: Frequency<T>?
Not sure. I guess adding generics to the Frequency class would eliminate the
use o CCE, but not sure if there is a use-case for keeping it as-is.
As a side note, this ClassCastException - as Michael pointed - is not an issue
for GWT. Only casting (e.g. SomeType a = (AnotherType) b) causes issues in GWT
apps - if I understood it correctly.
> Do not use exceptions for control flow
> --------------------------------------
>
> Key: MATH-1408
> URL: https://issues.apache.org/jira/browse/MATH-1408
> Project: Commons Math
> Issue Type: Task
> Reporter: Gilles
> Priority: Minor
> Labels: control, exception, flow
> Fix For: 4.0
>
>
> There are several occurrences where exception is used to control flow.
> Code such as
> {noformat}
> try {
> // block A
> } catch (ClassCastException e) {
> // block B
> }
> {noformat}
> where "block A" is trying to cast an object "o" to "SomeClass", should be
> changed to
> {noformat}
> if (o instanceof SomeClass) {
> // block A
> } else {
> // block B
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
