• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Tim Cooke
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Frank Carver
  • Henry Wong
  • Ron McLeod
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Himai Minh

ClassCastException not specified in the API for Map.remove

 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is very easy to produce a program that launches that exception when invoking Map.remove method, but the exception is not shown in the API. So I guess it is an error.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From the API-Documentation:

A method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught.

 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I understand that not being ClassCastException a checked exception it must not be declared or caught. I don't understand why this exception is specified in the Map.get method but not in the Map.remove.
I run an example with a TreeMap, later I changed the implementation for a HashMap. The keys were Integers. I have found that most of the ClassCastExeption that were launched before, were not now. I suppose that Integer.equals desn't launch ClassCastException.
Is it of importance to override equals in a way that launches that exception for a class that is going to be used as a key?
 
Ranch Hand
Posts: 1953
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ClassCastException
Read, please!

JavaChina has been moved to http://javachina.developergroup.org/
[This message has been edited by Roseanne Zhang (edited September 21, 2001).]
 
Roseanne Zhang
Ranch Hand
Posts: 1953
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
An important concept again:
Something must be specified does not imply Something else must not be specified
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is no absolute rule about how or whether to document unchecked exception. But a wise man once gave the following advice:


Use the Javadoc @throws tag to document each unchecked exception that a method can throw, but do not use the throws keyword to include unchecked exceptions in the method declaration. It is important that the programmer using your API be aware of which exceptions are checked and which are unchecked, as his responsibilities differ in these two cases. The documentation generated by the Javadoc @throws tag in the absence of the method header generated by the throws declaration provides a strong visual cue to help the programmer distinguish checked exceptions from unchecked.
It should be noted that documenting all of the unchecked exceptions that each method can throw is an ideal, not always achievable in the real world. [Example omitted]


This is from Effective Java, pp. 181-2, by Josh Bloch. By an amusing coincidence, Josh is also the one who wrote the Map interface you're asking about, as well as many other classes in the collections framework. (See the source code in src.jar to learn who wrote what, and more importantly, how it works under the hood.) As near as I can tell, it was a simple oversight (yes, even Josh can make mistakes) that remove() does not document the ClassCastException which it might throw. Certainly the implementation of TreeMap (written by Josh Bloch and Doug Lea) can throw a ClassCastException on remove() just as easily as for get() or put(). See the doc for the TreeMap() constructor for an explanation. Actually I don't see why you would have any trouble with a TreeMap whose keys are Integers - unless of course one of the keys was not an Integer, in which case the keys are not Comparable to each other, and ClassCastException is thrown. HashMap doesn't have this limitation - keys needn't be Comparable; they just have to have working hashCode() and equals() methods.

[This message has been edited by Jim Yingst (edited September 21, 2001).]
 
Roseanne Zhang
Ranch Hand
Posts: 1953
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim
You seems checking on me each time even I rarely have time to show up here.
BTW, I like the quotation you put here.
Roseanne
[This message has been edited by Roseanne Zhang (edited September 22, 2001).]
 
That is a really big piece of pie for such a tiny ad:
Garden Master Course kickstarter
https://coderanch.com/t/754577/Garden-Master-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic