NumberFormatException who throw it

[Sergej Smoljanov]

NumberFormatException for exam who throw this exception JVM or programmer?

[Blake Edward]

It's a runtime exception, a subclass of IllegalArgumentException which is a subclass of RuntimeException. This is thrown by the JVM but can also be thrown by the programmer from your own method with your own customized exception message. Also, a runtime exception can't be part of the method signature, even if your method throws it but you can use a try/catch block to manage it.

[Guillermo Ishi]

Blake Edward wrote: Also, a runtime exception can't be part of the method signature

This is legal if it's what you're referring to by signature

void tst () throws RuntimeException { }

[Roel De Nijs]

Blake Edward wrote:This is thrown by the JVM

Can you give an example? Or are you referring to e.g. Integer.parseInt(String string)? In my opinion that's not the JVM but a programmer, namely the programmer(s) who wrote the Integer class (according to java source code the authors are Lee Boynton, Arthur van Hoff, Josh Bloch and Joseph D. Darcy). And to prove it's coded by a programmer here are the first lines of the Integer.parseInt method:

if (s == null) {
  throw new NumberFormatException("null");
}
if (radix < Character.MIN_RADIX) {
  throw new NumberFormatException("radix " + radix + " less than Character.MIN_RADIX");
}
if (radix > Character.MAX_RADIX) {
  throw new NumberFormatException("radix " + radix + " greater than Character.MAX_RADIX");
}

Blake Edward wrote:Also, a runtime exception can't be part of the method signature, even if your method throws it but you can use a try/catch block to manage it.

Close, but not 100% true. Although it's not needed (as in the compiler won't complain) a runtime exception can be mentioned in the throws-clause in the method declaration. If a method throws a runtime exception (and isn't handled in the method itself), you can mention it in the throws-clause (exception list), but it's not required. That's the big difference with checked exceptions: if a method throws a checked exception (which again isn't handled in the method itself) it MUST be declared in the throws-clause (exception list), otherwise the compiler will complain and your code won't compile.

[Roel De Nijs]

Sergej Smoljanov wrote: NumberFormatException for exam who throw this exception JVM or programmer?

For me this exception is thrown programatically, not by the JVM. A NullPointerException, an AssertionError or a ClassCastException are examples of exceptions which are thrown by the JVM.

[Guillermo Ishi]

I've seen the JVM throw it too.

[Roel De Nijs]

Guillermo Ishi wrote:I've seen the JVM throw it too.

Can you give an example?

[Guillermo Ishi]

Roel De Nijs wrote:

Guillermo Ishi wrote:I've seen the JVM throw it too.

Can you give an example?

I've been thinking... I know I've encountered it. I'll get back in a bit.

[Guillermo Ishi]

Had to go buy smokes before the store closed..

It can be thrown by the JVM when something is entered at the keyboard or read from a stream, etc. and gets passed on down wthout checking to something that will throw it. Some situation where there's no type checking.

if (cost !=null && !"".equals(cost) ){
        try {
           Integer intCost = Integer.parseInt(cost);
           List<Book> books = bookService . findBooksCheaperThan(intCost);  
        } catch (NumberFormatException e) {
           System.out.println("This is not a number");
           System.out.println(e.getMessage());
        }
    }

I've never seen a distinction between thrown by the JVM and thrown by the author of the Integer class before, just the distinction between thrown by the application programmer, and thrown by anything else.

[Roel De Nijs]

Guillermo Ishi wrote:Had to go buy smokes before the store closed..

It's a bad habbit, so maybe it's a good thing the store closed before you could buy smokes

Guillermo Ishi wrote:It can be thrown by the JVM when something is entered at the keyboard or read from a stream, etc. and gets passed on down wthout checking to something that will throw it.

For me an exception is thrown by the JVM if in the source code file of any class no code (throw new XxxException()) is added to throw the exception. So for the NullPointerException you have a reference variable which is not initialized, you invoke a method on it and there you'll have it. You cast an object to another (invalid) class and the JVM thanks you with a ClassCastException
But for the NumberFormatException it's another story: if you look at the source code of Integer.parseInt you'll see 9 times a throw new NumberFormatException(message) statement (or something similar). So some programmer added the code to throw the exception, the JVM just executes the code. But if some developer removes these statements, the Integer.parseInt method wouldn't throw a NumberFormatException anymore.

Guillermo Ishi wrote:I've never seen a distinction between thrown by the JVM and thrown by the author of the Integer class before, just the distinction between thrown by the application programmer, and thrown by anything else.

There is always a first time for everything I just had a look in my copy of the K&B6 book and the NumberFormatException is categorized as "programatically" (not "JVM").

[Guillermo Ishi]

Next step you should see if you can find K&B saying something's thrown by JVM when it's really thrown by the class library, to be fair.

Roel De Nijs wrote:It's a bad habbit, so maybe it's a good thing the store closed before you could buy smokes

It's ok. Since I started Java I got nothing to live for

[Roel De Nijs]

Guillermo Ishi wrote:Next step you should see if you can find K&B saying something's thrown by JVM when it's really thrown by the class library, to be fair.

K&B6 handles 10 exceptions and errors mentioned in the exam objectives. Here is an overview:

By the JVM

ArrayIndexOutOfBoundsException

ClassCastException

NullPointerException

ExceptionInInitializerError

StackOverflowError

NoClassDefFoundError

Programmatically

IllegalArgumentException

IllegalStateException

NumberFormatException

AssertionError

I can agree with all of them, except the AssertionError. I would put that one in the "By the JVM" category.

As an extra note: of course you can throw some of the exceptions in the "By the JVM" category also programatically. For example:

public int length(String str) {
  if (str == null) {
    throw new NullPointerException("[str] is required");
  }
  return str.length();
}

So in this example the NullPointerException is thrown programatically. If I would remove the if-statement entirely, the NullPointerException (when I pass a null value to the length method) is thrown by the JVM.

[Paul Anilprem]

Roel De Nijs wrote:
K&B6 handles 10 exceptions and errors mentioned in the exam objectives. Here is an overview:

By the JVM

ArrayIndexOutOfBoundsException

ClassCastException

NullPointerException

ExceptionInInitializerError

StackOverflowError

NoClassDefFoundError

Programmatically

IllegalArgumentException

IllegalStateException

NumberFormatException

AssertionError

I can agree with all of them, except the AssertionError. I would put that one in the "By the JVM" category.

Good point about AssertionError.

One exception that is missing from the above list (and from the book if you included all of them from the book) is java.lang.ArithmeticException. There are questions in the exam that expect you to know about this exception. This is thrown by the JVM when you try to divide by zero.

As an extra note: of course you can throw some of the exceptions in the "By the JVM" category also programatically. For example:

public int length(String str) {
  if (str == null) {
    throw new NullPointerException("[str] is required");
  }
  return str.length();
}

So in this example the NullPointerException is thrown programatically. If I would remove the if-statement entirely, the NullPointerException (when I pass a null value to the length method) is thrown by the JVM.

If you check an argument and if you decide that the method cannot work with the given argument, for whatever reason, you should throw an IllegalArgumentException. It is technically possible to throw a NullPointerException explicitly, but IllegalArgumentException is more appropriate.

-Paul.

[Roel De Nijs]

Paul Anilprem wrote:One exception that is missing from the above list (and from the book if you included all of them from the book) is java.lang.ArithmeticException. There are questions in the exam that expect you to know about this exception. This is thrown by the JVM when you try to divide by zero.

It's the study guide for the OCPJP6 exam, so it's not really missing in the book. For that exam you just need to know the 10 exceptions/errors which I listed above (the OCPJP6 exam objectives can be found here). I just checked the exam objectives for OCAJP7. The applicable exam objective is pretty vague: Recognize common exception classes and categories. With such a general objective, Oracle can add/change the list of required exceptions without having to change the exam objectives accordingly. A nightmare for book authors
Just to compare, the same exam objective for OCPJP6: Recognize situations that will result in any of the following being thrown: ArrayIndexOutOfBoundsException,ClassCastException, IllegalArgumentException, IllegalStateException, NullPointerException, NumberFormatException, AssertionError, ExceptionInInitializerError, StackOverflowError or NoClassDefFoundError. Understand which of these are thrown by the virtual machine and recognize situations in which others should be thrown programatically.

Paul Anilprem wrote:If you check an argument and if you decide that the method cannot work with the given argument, for whatever reason, you should throw an IllegalArgumentException. It is technically possible to throw a NullPointerException explicitly, but IllegalArgumentException is more appropriate.

First of all, my code snippet was for didactic purposes only. No way I was trying to make a statement or introduce a best practice about how people should code

Secondly, I'm pretty sure we could have a seperate discussion about which approach is more desirable/appropriate and I guess in the end it might be undecided. And I certainly don't want to start this discussion here (maybe we can start a seperate thread in another forum), but I just want to mention a few reasons why throwing NullPointerException could be considered more appropriate than IllegalArgumentException:

already used in the Java API (e.g. Map.containsKey)

Effective Java 2nd Edition, Item 60: "Arguably, all erroneous method invocations boil down to an illegal argument or illegal state, but other exceptions are standardly used for certain kinds of illegal arguments and states. If a caller passes null in some parameter for which null values are prohibited, convention dictates that NullPointerException be thrown rather than IllegalArgumentException. Similarly, if a caller passes an out-of-range value in a parameter representing an index into a sequence, IndexOutOfBoundsException should be thrown rather than IllegalArgumentException."

in Java 7 a new class Objects was introduced (in the java.util package), its (static) method requireNonNull throws a NullPointerException if the object is null

Finally, in my own code/projects I always throw an IllegalArgumentException when the argument is illegal, no matter for which reason. I think in the end it's nothing more but a style question. Both alternatives are good and everyone will have his/her preference. And it is probably less important which of these exceptions you choose, but much more important that you stay with your choice and use the exception consistently in your projects.

[Paul Anilprem]

Roel De Nijs wrote:

Paul Anilprem wrote:One exception that is missing from the above list (and from the book if you included all of them from the book) is java.lang.ArithmeticException. There are questions in the exam that expect you to know about this exception. This is thrown by the JVM when you try to divide by zero.

It's the study guide for the OCPJP6 exam, so it's not really missing in the book. For that exam you just need to know the 10 exceptions/errors which I listed above (the OCPJP6 exam objectives can be found

You are right. I missed that part about OCPJP6.

Paul Anilprem wrote:If you check an argument and if you decide that the method cannot work with the given argument, for whatever reason, you should throw an IllegalArgumentException. It is technically possible to throw a NullPointerException explicitly, but IllegalArgumentException is more appropriate.

First of all, my code snippet was for didactic purposes only. No way I was trying to make a statement or introduce a best practice about how people should code

I am sure you were not trying to make a statement or introduce a best practice. I was just adding another perspective. Didn't mean to question your judgement there. Very sorry if you felt offended.

Secondly, I'm pretty sure we could have a seperate discussion about which approach is more desirable/appropriate and I guess in the end it might be undecided. And I certainly don't want to start this discussion here (maybe we can start a seperate thread in another forum), but I just want to mention a few reasons why throwing NullPointerException could be considered more appropriate than IllegalArgumentException:

already used in the Java API (e.g. Map.containsKey)

Effective Java 2nd Edition, Item 60: "Arguably, all erroneous method invocations boil down to an illegal argument or illegal state, but other exceptions are standardly used for certain kinds of illegal arguments and states. If a caller passes null in some parameter for which null values are prohibited, convention dictates that NullPointerException be thrown rather than IllegalArgumentException. Similarly, if a caller passes an out-of-range value in a parameter representing an index into a sequence, IndexOutOfBoundsException should be thrown rather than IllegalArgumentException."

in Java 7 a new class Objects was introduced (in the java.util package), its (static) method requireNonNull throws a NullPointerException if the object is null

Thanks for sharing these details. You are right that this merits a separate discussion.

Finally, in my own code/projects I always throw an IllegalArgumentException when the argument is illegal, no matter for which reason. I think in the end it's nothing more but a style question. Both alternatives are good and everyone will have his/her preference. And it is probably less important which of these exceptions you choose, but much more important that you stay with your choice and use the exception consistently in your projects.

Right again

[Roel De Nijs]

Paul Anilprem wrote:Didn't mean to question your judgement there. Very sorry if you felt offended.

No worries! I was not offended

Paul Anilprem wrote:You are right that this merits a separate discussion.

If you are interested to join that discussion, just click here