Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Confusing example using the RuntimeException class in the OCA JavaSE7 Guide (Mala Gupta)

 
Mohammad Ali Asgar
Ranch Hand
Posts: 39
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Experts,

In the OCA Java SE7 Certification Guide, I read the following excerpts in 7.2.6 regarding exceptions:

"You can rethrow a runtime exception, but you are not required to catch it, nor must you modify your method signature to include the throws clause. The simple reason for this rule is that RuntimeExceptions are not checked exceptions, and they may not be caught or declared to be thrown by your code."

Then, when I went down to Twist in the Tale 7.2, which is about nested try-catch-blocks, I found that the NullPointerException class is being used in a "catch" clause. But, NullPointerException is a subclass of RuntimeException!

Yes, I understand that the objective of Twist in the Tale 7.2 is to test the reader's ability to work out a solution for nested try-catch blocks. But, why is a RuntimeException being explicitly caught in a catch clause in the example - a practice that the writer herself deems not advisable (or, prohibited ?) on a previous page (as I have quoted above)?

__ softwarelover


 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35266
383
Eclipse IDE Java VI Editor
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's a language thing. The author meant "and they do not have to be not be caught or declared to be thrown by your code".

The problem is "may not" means two things in English depending on where you put the emphasis:
1) you may NOT - means you are not allowed to
2) you MAY not - you might or might not do something

In this case, I can tell the author meant definition #2 from the context (and knowing the rules)
 
Mohammad Ali Asgar
Ranch Hand
Posts: 39
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
LOL
 
Paul Clapham
Sheriff
Posts: 21546
33
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I guess that if the author had meant Jeanne's #1, they would have written "must not" rather than "may not". But even though I'm a native speaker of English I find "may not" to be misleading, and I would much prefer something clearer. You'll notice that Jeanne used "might" in her #2, but "might" versus "may" don't work the same even for English speakers of the same dialect, so that's not the way to go either.
 
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
Jeanne Boyarsky wrote:The problem is "may not" means two things in English depending on where you put the emphasis:
1) you may NOT - means you are not allowed to
2) you MAY not - you might or might not do something

And then they dare to say: Dutch is a hard language I don't think it's a very good idea for a book to have a meaning of a sentence rely on the emphasis

I agree with Jeanne: although it's not required to catch or declare a runtime exception, that doesn't mean you could not do it. If you are in doubt, you can always ask a little advice (here or) from the java compiler. That guy is never wrong and is very straightforward in his explanation. If it isn't allowed, you'll definitely know it. Without any doubt!

A little code example to experiment with:


What would happen if you try to compile this class? And if you change every occurence of NullPointerException with IOException will the result (of compilation) be the same?
 
Mohammad Ali Asgar
Ranch Hand
Posts: 39
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Roel for the code. I have tried to compile the code you wrote.

It compiles just fine in the case of NullPointerException. It seems it is optional for a method to declare that it throws NullPointerException, which is a type of runtime exception. But, in the book the wording "must not declare that it throws runtime exceptions" made me think that it would be prohibited for a method to declare that it throws runtime exceptions. So, for runtime exceptions, the "throws" clause is optional, not forbidden. But using the throws clause makes it funny since it implies that the programmer is expecting some "programming errors" to exist in his/her code!

Another observation is that the code does not need to import NullPointerException, which I find quite logical, since it is about runtime.

In the case of IOException, which is a compile-time/checked exception, it does not compile. An "import" statement is required for IOException in order for the compiler to recognize it. Again, that is logical, since it is checked at compile-time. The compiler reports an error on methodA which does not have a throws clause. So, the throws clause is mandatory if the method throws a checked-exception.
 
Joanne Neal
Rancher
Posts: 3742
16
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mohammad Ali Asgar wrote:Another observation is that the code does not need to import NullPointerException, which I find quite logical, since it is about real-time.

In the case of IOException, which is a compile-time/checked exception, it does not compile. An "import" statement is required for IOException in order for the compiler to recognize it. Again, that is logical, since it is checked at compile-time.

That has nothing to do with checked and unchecked exceptions. The reason you don't need to import NullPointerException is that it is in the java.lang package and all classes in that package are imported automatically.
There are several checked excpeptions in the java.lang package that you also wouldn't have to import - CloneNotSupportedException, Exception, InterruptedException to name a few.
 
Joanne Neal
Rancher
Posts: 3742
16
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mohammad Ali Asgar wrote:...real-time exception...real-time exceptions...real-time exceptions...real-time exceptions.

runtime exception
 
Mohammad Ali Asgar
Ranch Hand
Posts: 39
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Joanne! I didn't know it about java.lang.*!

I have replaced the "real-time" with runtime. What was I thinking...!
 
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
Mohammad Ali Asgar wrote:Another observation is that the code does not need to import NullPointerException, which I find quite logical, since it is about runtime.

In the case of IOException, which is a compile-time/checked exception, it does not compile. An "import" statement is required for IOException in order for the compiler to recognize it. Again, that is logical, since it is checked at compile-time.

Like already mentioned by Joanne the reason why NullPointerException doesn't need an import statement and IOException does, is simply because NullPointerException is in the java.lang package (classes in this package are imported automatically) and IOException is in a different package (the java.io package and you have to provide the import yourself). It has nothing to do with unchecked or checked exceptions!

Of course the purpose of my exercise/question was not the required import for IOException. That actually slipped my mind resulting in a poor exercise/question. In the end you have learned something you didn't know (about the java.lang package), so the exercise/question was not complete waste of time

Let's start over again and use a better exercise/question this time. A little code example to experiment with:


What would happen if you try to compile this class? And if you change every occurence of NullPointerException with InterruptedException will the result (of compilation) be the same?

Much better!
 
Mohammad Ali Asgar
Ranch Hand
Posts: 39
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Scenario1: NullPointerException [unchecked/runtime]
Scenario2: InterruptedException [checked/compile-time]

The code compiled as-is works fine proving that for runtime exceptions the "throws" clause is optional in a method signature. But if NullPointerException is replaced by InterruptedException, then the compiler reports an error that in the signature of methodA the "throws" clause is missing. That indicates that it is mandatory for a method to declare that it throws a checked exception, if there is a "throw" statement within that method.

 
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
Mohammad Ali Asgar wrote:But if NullPointerException is replaced by InterruptedException, then the compiler reports an error that in the signature of methodA the "throws" clause is missing. That indicates that it is mandatory for a method to declare that it throws a checked exception, if there is a "throw" statement within that method.

Not 100% correct, but you are almost there! For a checked exception there is the handle-or-declare rule. You must either handle the checked exception (putting the risky code into a try/catch) or declaring the checked exception (add a throws-clause to the method's declaration). So in this exercise you have 2 options 2 make the compiler happy:

A. handle the checked exception


B. declaring the checked exception


And what would happen if you combine both options? So if you would handle-and-declare the checked exception?

Ooh, so much fun with such a small code snippet
 
Mala Gupta
Author
Ranch Hand
Posts: 363
11
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ali,

I agree with your suggestion and have rephrased:

"You can rethrow a runtime exception, but you are not required to catch it, nor must you modify your method signature to include the throws clause. The simple reason for this rule is that RuntimeExceptions are not checked exceptions, and they may not be caught or declared to be thrown by your code."

to-

"You can rethrow a runtime exception. Though you can, you are not neither required to catch it, nor required to modify your method signature to throw it. The simple reason for this rule is that RuntimeExceptions are not checked exceptions-though allowed, they need not be caught or declared to be thrown by your code."

I've also added it to the book's errata (the official errata takes a while to update).

Jeanne, Paul, Joanne and Roel-Thanks for answering the query.

Roel De Nijs wrote:And what would happen if you combine both options? So if you would handle-and-declare the checked exception?
Ooh, so much fun with such a small code snippet

Let me try-

Even though methodA() in the preceding code doesn't actually throw the IOException, the compiler allows it to be included in the throws statement. So you can do both-catch an exception and declare it to be thrown.

It is interesting to note that a method can declare any exception to be thrown, even if it doesn't throw it:


Can you 'catch' an exception, if the enclosing try block doesn't throw it?

Try to compile the following code-



Will the preceding code compile, when IOException is replaced by-


With much respect,
Mala
 
Satya D Prasad
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Checked exceptions are those which are subject to catch-or-specify requirement. Either catch them using try-catch blocks or specify them using the throws clause in the method declaration. Any piece of code that violates this rule for checked exception doesn't compile. Unchecked exceptions, I mean, java.lang.RuntimeException and java.lang.Error are not subject to this requirement.
 
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
Mala Gupta wrote:So you can do both-catch an exception and declare it to be thrown.

Spot-on!

Mala Gupta wrote:Can you 'catch' an exception, if the enclosing try block doesn't throw it?

It depends on which kind of exception. If it is a checked exception (subclass of Exception but not of RuntimeException), you'll get a compiler error. Otherwise the code will compile successfully.

Mala Gupta wrote:Will the preceding code compile, when IOException is replaced by-

  • IOException --> compiler error
  • Exception, RuntimeException & Throwable --> compiles without errors
  •  
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic