• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

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

 
Ranch Hand
Posts: 39
1
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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


 
author & internet detective
Posts: 42102
933
Eclipse IDE VI Editor Java
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
LOL
 
Sheriff
Posts: 28368
99
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Rancher
Posts: 3742
16
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Author
Posts: 375
22
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  •  
    Ruth Stout was famous for gardening naked. Just like this tiny ad:
    We need your help - Coderanch server fundraiser
    https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
    reply
      Bookmark Topic Watch Topic
    • New Topic