commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-1408) Do not use exceptions for control flow
Date Thu, 06 Apr 2017 00:33:42 GMT

    [ 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)

Mime
View raw message