try-catch blocks, exception processing and the HashMap get method

[Vince Mansel]

I was recently experimenting with a try-catch block while dealing with the get method on a HashMap object instance.

The compiler does not require a try-catch (indeed that may be the answer) but in the Java API,
the Map interface (which HashMap implements) says it the get method throws two
different exceptions.

Why doesn't the compiler require a try-catch block around the get method?

When is it "appropriate" to use try catch exception processing other than when it is required by the compiler?

[paul wheaton]

Tell us the two exceptions. And then tell us what those exceptions extend.

[Prateek Parekh]

Also, you might want to review "Checked" and "Unchecked" exceptions.

[Vince Mansel]

Thanks. I think I got it.

The HashMap extends AbstractMap and implements Map. But according to the API spec,
the HashMap get method does not document that it throws exceptions although the Map interface does and
specifies two: NullPointerException and ClassCastExceptions, both of which extend RuntimeException.

Examining the API for RuntimeException documents:

"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."

Runtime exceptions are unchecked by the compiler.

[Gary Ba]

Runtime exceptions are unchecked by the compiler.

So this means the code needs to fix the runtime exceptions. In this case, check the NULLS.

thanks,
gary