[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Jeanne Boyarsky wrote:That question doesn't say "choose all that apply" which means you are supposed to choose the best single answer. Choice A includes throwing a specific stack trace so it is the best answer. If the code threw a NullPointerException say, then the answer would be choice G (and not choice A.)
Also, I added the word "Wiley" to the subject of both your threads. There are multiple OCA 8 study guides out now so we want it to be obvious to other posters which threads are about which. I of course knew because I recognized our questions .
Jeanne Boyarsky wrote:If the code threw a NullPointerException say, then the answer would be choice G (and not choice A.)
Roel De Nijs wrote:
Jeanne Boyarsky wrote:If the code threw a NullPointerException say, then the answer would be choice G (and not choice A.)
That's not 100% correct If a NullPointerException was thrown inside the try block, the NullPointerException would definitely be caught by the catch block on line 9 and thus it would not have been an uncaught exception. So an ArrayIndexOutOfBoundsException would have been a better example for choice G
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Micheal Bush wrote:Why does "int x = Integer.parseInt(name);" throw a NumberFormatException? It should throw a NPE which makes more sense.
Junilu Lacar wrote:
Micheal Bush wrote:Why does "int x = Integer.parseInt(name);" throw a NumberFormatException? It should throw a NPE which makes more sense.
Not really. The JavaDocs for the two-argument version of parseInt() clearly states that a NumberFormatException will be thrown if the value to be parsed is null or an empty string. Null or empty string is not parseable to an integer so I don't see why it would be less appropriate to throw a NFE than a NPE. If anything, expecting NPE implies certain assumptions about the implementation of the parseInt() method which, in my opinion, would be inappropriate. Besides, a NPE usually points to a programming error and in this case, a null or empty string is clearly something you would want to check and explicitly flag as unacceptable input.
If one were to argue for a different exception, an IllegalArgumentException might be a more logical alternative. I still concur with choosing NumberFormatException though.
Micheal Bush wrote:
If you read API of Double.parseDouble, you will find:
Throws:
NullPointerException - if the string is null
NumberFormatException - if the string does not contain a parsable double.
Least of all in the earlier versions of Java®. I would have used that sort of exception myself, but, as I said before, that is a good way to start arguments.Junilu Lacar wrote:
Micheal Bush wrote:
If you read API of Double.parseDouble, you will find:
Throws:
NullPointerException - if the string is null
NumberFormatException - if the string does not contain a parsable double.
Nobody ever accused the authors of the standard library of being consistent or perfect. . . .
My name is Inigo Montoya, you killed my father, prepare to read a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|