Win a copy of TensorFlow 2.0 in Action this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

NumberFormatException thrown programmatically

 
Greenhorn
Posts: 11
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Master Rancher
Posts: 3704
44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 395
8
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Greenhorn
Posts: 11
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi @ all
Thank you so much for helping me out with that Topic and I got the Point now
 
Charles O'Leary
Ranch Hand
Posts: 395
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.

 
Marshal
Posts: 70718
288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:-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
Greenhorn
Posts: 11
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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:-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:)
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 70718
288
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh! there are a lot of them!
Thank you!
 
Saloon Keeper
Posts: 22678
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Try 100 things. 2 will work out, but you will never know in advance which 2. This tiny ad might be one:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic