NumberFormatException thrown programmatically

[Aleana Cologne]

Hi everybody,

Maybe someone can enlighten me:)

In OCA Study guid for OCA 8 from Boyarski and Selikoff. In Chapter 6 ( and in Javadoc from Oracle) NumberFormatExceptions are a child class of RunTimeException. this far I understand the Point with checked and unchecked.

But than in the Review Questions of that chapter , Question 5 I am asked  which of the following exceptions are thrown by the JVM and
obviously i choosed NumberFormatException as  an answer.

But it isn't thrown by JVM as the solution told me but a programmatically thrown one through Wrapper class.

And this is something I don't get right.

Because nearly everywhere I was told Runtime Exception are thrown by JVM ..
I marked this as something  like a rule to remember , but now ;( …

Is there someone to explain that to me ? Or is it just a Special kind of rule I have to remember , and if yes,are there some more specialties coming with that topic ?

Thanks for helping me out
Alex

[Mike Simmons]

All "exceptions" (Throwables) thrown by the JVM are either RuntimeExceptions, or Errors.  However, not all RuntimeExceptions or Errors are thrown by the JVM.  There are many, many cases where these can be thrown programmatically as well.  Even specific exceptions that are thrown by the JVM, like NullPointerException or ClassCastException, may be thrown programmatically as well, if someone feels like writing code that does that.

So, you can learn specific situations where the JVM will throw a RuntimeException, or an Error.  But never assume that's the only way that RuntimeException or Error can be thrown.

[Charles O'Leary]

Aleana Cologne wrote:Hi everybody,

Maybe someone can enlighten me:)

In OCA Study guid for OCA 8 from Boyarski and Selikoff. In Chapter 6 ( and in Javadoc from Oracle) NumberFormatExceptions are a child class of RunTimeException. this far I understand the Point with checked and unchecked.

But than in the Review Questions of that chapter , Question 5 I am asked  which of the following exceptions are thrown by the JVM and
obviously i choosed NumberFormatException as  an answer.

But it isn't thrown by JVM as the solution told me but a programmatically thrown one through Wrapper class.

And this is something I don't get right.

Because nearly everywhere I was told Runtime Exception are thrown by JVM ..
I marked this as something  like a rule to remember , but now ;( …

Is there someone to explain that to me ? Or is it just a Special kind of rule I have to remember , and if yes,are there some more specialties coming with that topic ?

Thanks for helping me out
Alex

Thanks Aleana for this question.  Welcome to the Ranch!  This wasn't on my radar until you pointed it out!  

Mike Simmons wrote:There are many, many cases where these can be thrown programmatically as well.  Even specific exceptions that are thrown by the JVM, like NullPointerException or ClassCastException, may be thrown programmatically as well, if someone feels like writing code that does that.

So, you can learn specific situations where the JVM will throw a RuntimeException, or an Error.  But never assume that's the only way that RuntimeException or Error can be thrown.

To Mike's point, From the book you referenced in the Runtime Exceptions section:

They can be thrown by the programmer or by the JVM.

 Thus, the "only" rule is that

They don't have to be handled or declared.

[Aleana Cologne]

Hi @ all
Thank you so much for helping me out with that Topic and I got the Point now

[Charles O'Leary]

Aleana Cologne wrote:Hi @ all
Thank you so much for helping me out with that Topic and I got the Point now

Thanks again Aleana for highlighting this canned gotcha!  Indeed, according to Oracle

RuntimeException is the superclass of those exceptions that  can be thrown during the normal operation of the Java Virtual Machine.

[Campbell Ritchie]

How are you supposed to know that the wrapper class throws such exceptions? Does it say anything in the book or the documentation that the method throws its own exceptions?
Gp and look through your Java® installation folder; there is a file called src.zip in there (at least there often is). Unzip that file and go to the .../java.base/java/lang/Integer.java file, and in the code for the parseInt(String, int) method, you will find all sorts of lines like this:-

if (something) {
   throw new NumberFormatException("something");
}

That confirms what CO'L told you about how such exceptions are thrown, but how would you know without looking at the source?

[Aleana Cologne]

Campbell Ritchie wrote:How are you supposed to know that the wrapper class throws such exceptions? Does it say anything in the book or the documentation that the method throws its own exceptions?
Gp and look through your Java® installation folder; there is a file called src.zip in there (at least there often is). Unzip that file and go to the .../java.base/java/lang/Integer.java file, and in the code for the parseInt(String, int) method, you will find all sorts of lines like this:-

if (something) {
   throw new NumberFormatException("something");
}

That confirms what CO'L told you about how such exceptions are thrown, but how would you know without looking at the source?

Thats exactly what I did before I thanked earlier for helping me ;)

But anyway Thanks again for telling me the source to find it:)

[Teodor Ian]

Hi,

I learn also for OCA Exam and I identify so far two of this kind of exceptions (RuntimeException which are throws programmatically)

1. IllegalArgumentException
2. NumberFormatException

Are there more of them?

Thank you,
Theodor

[Campbell Ritchie]

Unzip src.zip and look for .../java.base/java/util/Scanner.java. You might find code throwing input mismatch exceptions or no such element exceptions thrown.
Go through .../java.base/java/util/Objects.java and look for the versions of the requireNonNull(...) method.

[Teodor Ian]

Oh! there are a lot of them!
Thank you!

[Tim Holloway]

An important thing to remember is that, as much as possible, Java is implemented in Java. Yes, NumberFormatException is thrown by "the JVM", but there's no magic there and I could just as easily throw a NumberFormatExpression manually, if I wanted. The only constraint is that if I didn't want to be pursued by angry mobs, I wouldn't do it in ways that would confuse people reading my code.

Actually, NumberFormatException isn't thrown by the JVM except in the sense that all Throwable's are thrown by the JVM. The NumberFormatException is thrown by classes such as java.lang.Integer. And, as I said, as much of Java as is possible is written in Java, including all the non-native code of the built-in classes that come with the JVM. As Campbell illustrated, there's Java source code for it. Which isn't just being nice - it's also useful when debugging.

As an aside, Java-in-Java has 3 justifications:

1. Eating your own dog food. A good programming language is judged by how much "outside help" it requires.
2. Portability. Since Java code is (supposed-to-be) "write once/run anywhere", you can port a Java implementation faster if the build of it is portable code.
3. Maintainer base. For any given Java platform, there are likely to be far more people who can work with Java than can work with whatever parts of the JVM are not Java and thus are platform specific. For the non-portable parts you'd need expertise in developing for and maintaining code for the platform of interest. One developer team per platform, as a rule.