• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NumberFormatException who throw it

 
Sergej Smoljanov
Ranch Hand
Posts: 467
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
NumberFormatException for exam who throw this exception JVM or programmer?
 
Blake Edward
Ranch Hand
Posts: 105
4
Java Netbeans IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 789
C++ Linux Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:


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
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 789
C++ Linux Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've seen the JVM throw it too.


 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guillermo Ishi wrote:I've seen the JVM throw it too.

Can you give an example?
 
Guillermo Ishi
Ranch Hand
Posts: 789
C++ Linux Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 789
C++ Linux Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.




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
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 789
C++ Linux Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

    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
    Enthuware Software Support
    Ranch Hand
    Posts: 3817
    10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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:

    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
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Enthuware Software Support
    Ranch Hand
    Posts: 3817
    10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic