ommission of throws legal?

[Paul Salerno]

class A
{
   public void method() throws IOException
   {
   }
}
class B extends A
{
   public void method()
   {
   }
}

the method() in B doesnt have to throw same exception.

class A
{
   public static void main(String[] args)
   {
      B myref = new B()
      try
      {
         myref.test()
      }
      catch(IOException ioe)
      {
      }
   }
   void test() throws IOException
   {
      throw new IOException()
   }
}
class B extends A
{
   void test() // compiler error in this case
   {
   }
}

however in this case the calling of B's test() is within a try/catch. Is this the only reason why it cannot ommit the checked exception listed in test() of parent?

[Corey McGlone]

What is the compiler error you're getting? My guess is that you're getting an "Unreachable block" error, but I wish you would have said.
Anyway, my guess is that, since you have a catch block that can catch an IOException, it would seem that you're expecting the method to be able to throw an IOException but, as you've defined the method test() in class B, it can't throw any checked exceptions.
Therefore, the compiler states that the code in the catch block in "unreachable" because there is no case in which that method can throw an IOException.
An overridden method from a parent class can throw any subset of the exceptions the overridden method can throw. According to that, your definition of test() in B is correct.
Corey

[Brian Lugo]

Hi Paul!
What do you think of the code below:

class A{
public void method() throws Exception   {  throw new Exception(); }
}
class B extends A{
public void method()   {System.out.println("I am in method of B");   }
}
public class TestThrowsinDer {
public static void main(String[] args) {
B myref = new B();

try{
myref.method();
}
finally {
}
}
}

It compiles and executes fine.

[Shivaji Marathe]

First of all, all the semicolons are missing. So it will not compile.
Even after putting the semi colons back, in the main method you are calling the test method of the descendant object, which never throws any IO exception, yet the call to that method is enclosed in a try block.
HTH

[Jose Botella]

In a nutshell: you need to throw the checked exceptions you cacth. But you don't need to throw any exception that you declare.

[Brian Lugo]

I am not at all happy with the person who started this thread!!!
Here is the code that you were trying to print here, I guess. The only thing I have changed is IOException to Exception and added semi-colon statements so there is no compiling errors:

class TestThrows {
public static void main(String[] args) { 
B myref = new B();
try      { 
myref.test();
}      catch(Exception ioe)      {
}   
}   
void test() throws Exception   { 
throw new Exception();
}
}
class B extends TestThrows{ 
void test() // compiler error in this case 
{   
}
}

This code compiles and runs perfectly ok.
Come on man!! You gotta atleast code properly first.
Stop confusing people for no reason.
Jose your statements are not correct. Take a look at the code mentioned by me in my previous post.
[ February 08, 2002: Message edited by: Brian Lugo ]
[ February 08, 2002: Message edited by: Brian Lugo ]

[Paul Salerno]

Brian,
I appreciate your help, but kind of resent your comments. I'm a beginner here thanks!
I got this code from a text book, where it states that the call to test() in B will result in a compiler error because it doesnt have a throws. So this example in the book is incorrect?

[Brian Lugo]

Hi Paul!
No offense! I got a bit carried away and apologize. Here are couple of steps that will help you in the certification path and posting messages here:
1. You gotta have a computer and JAVA/good editor installed on your computer.
2. Whenever in doubt try exploring your question by yourself, by typing the code and executing it.
3. Check for all the syntax errors.
4. Try coding programs for the concepts you have a qestion about.
If you won't make an effort to program you will have a tough time dealing with the syntax and the questions will appear more tougher.
Coding will definitely give you the confidence you need to deal with SCJP.
I apologize once again,
I hope this helps,
Brian
PS - You may want to check out the FAQ links mentioned by Valentin in his earlier posts.

[Paul Salerno]

Thank you for your helpful advice.
Yes I agree if I had downloaded the JVM on my computer and was able to compile this program before I posted I would indeed find the errors. But FYI I'm unable to do this right now, so rather than just do nothing (and post no question at all) I took an example that I received from an earlier text book.
So basically I'm still left with the same question I started with. Here's the original code (which I know wont compile):

 
class A{   
   public static void main(String[] args)
   {      
      B myref = new B()      
      try      
      {         
         myref.test()      
      }      
      catch(IOException ioe)      
      {      
      }   
   }   
   void test() throws IOException   
   {      
      throw new IOException()   
   }
}
class B extends A
{   
   void test() // compiler error 
   {
   }
}

[Valentin Crettaz]

The compiler error you are getting is just because method test in B doesn't throw any IOException and thus there is nothing to catch.
An overriding method doesn't need to throw the Exception thrown by the overridden method. The only thing it cannot do is throw "more" Exceptions than the overridden method throws.
In clear, an overriding method may throw:
- the same Exception as the overridden method
- a subclass of it
- a RuntimeException or its subclasses
- or nothing
Here, method test in B fulfills those requirements (the last one) so there is no problem. The only problem is that you enclose the invocation to test in a try-catch block and the compiler doesn't like it because there won't be any IOException thrown from method test in class B.
Now the tricky part is this:
If instead of having
B myref = new B();
you had
A myref = new B();
then the try-catch is mandatory because you may well create an instance of A. The compiler doesn't know that you create an instance of B and requires the try-catch block in the case you have an object of type A and you invoke method test on it (which may throw an IOException).
I hope that clears your doubts.

[Brian Lugo]

Hi Paul!
If you don't mind me asking, what book are you refering to?
Brian

[Paul Salerno]

Thanks everyone.

[Brian Lugo]

Valentin you are not correct!
Could you please validate your post by compiling and running the code that I have provided with class TestThrows.
Thanks,
Brian
[ February 08, 2002: Message edited by: Brian Lugo ]

[Paul Salerno]

Brian,
I PM'd you
-Paul

[Brian Lugo]

Originally posted by Valentin Crettaz:
The compiler error you are getting is just because method test in B doesn't throw any IOException and thus there is nothing to catch.
An overriding method doesn't need to throw the Exception thrown by the overridden method. The only thing it cannot do is throw "more" Exceptions than the overridden method throws.
In clear, an overriding method may throw:
- the same Exception as the overridden method
- a subclass of it
- a RuntimeException or its subclasses
- or nothing
Here, method test in B fulfills those requirements (the last one) so there is no problem. The only problem is that you enclose the invocation to test in a try-catch block and the compiler doesn't like it because there won't be any IOException thrown from method test in class B.
Now the tricky part is this:
If instead of having
B myref = new B();
you had
A myref = new B();
then the try-catch is mandatory because you may well create an instance of A. The compiler doesn't know that you create an instance of B and requires the try-catch block in the case you have an object of type A and you invoke method test on it (which may throw an IOException).
I hope that clears your doubts.

I don't think any compiler error results in this code. So, I do not understand when you say "The compiler error you are getting".
Also, "The only problem is that you enclose the invocation to test in a try-catch block and the compiler doesn't like it because there won't be any IOException thrown from method test in class B."

I agree with this:
"A myref = new B();
then the try-catch is mandatory because you may well create an instance of A. The compiler doesn't know that you create an instance of B and requires the try-catch block in the case you have an object of type A and you invoke method test on it (which may throw an IOException)."
Brian

[Valentin Crettaz]

I post the code so that everybody talks about the same code:

import java.io.*;
class Test {
    public static void main(String[] args) { 
B myref = new B();
try      { 
    myref.test();
}catch(IOException ioe){ //compiler-error here
}   
    }   
    void test() throws IOException   { 
throw new IOException();
    }
}
class B extends Test{ 
    void test() {
    }
}

There is a compile-time error here because method test in B does not throw any checked exception expected by the try-catch block in main.
Now if you change IOException to Exception, then it won't result in a compile-time error because Exception encompass both checked and unchecked exceptions and unchecked exceptions may arise anytime and do not need to be caught.
HIH

[Paul Salerno]

Valentin,
How much do I owe you?
Your explanations and comments are extremely helpful and very easy to understand.
-Paul

[Valentin Crettaz]

How much do I owe you?

a beer sometime

Your explanations and comments are extremely helpful and very easy to understand.

Well, thanks but that's part of the game

[Brian Lugo]

Thanks for clarifying. My bad - I changed IOException to Exception.
Gotta get my class path straightened out!!!
Sorry for the confusion - every body!
What's a good Swiss Beer Valentin?
Are there any on line stores where I can order a good Beer for you?
Brian
[ February 08, 2002: Message edited by: Brian Lugo ]

[Valentin Crettaz]

My bad - I changed IOException to Exception.

You naughty boy

Gotta get my class path straightened out!!!

You better or you don't get any dessert otherwise
(sorry I'm just too happy today, I guess I'm gonna take off for one or twelve beers )
[ February 08, 2002: Message edited by: Valentin Crettaz ]

[Brian Lugo]

Check out my above POST - you definitely deserve couple of Beers .

[Valentin Crettaz]

Sounds like I'm gonna get drunk before the day is over
Actually, Switzerland is not very good at brewing beers, I'd say chocolate is its best feature (among others of course ).
Well, no need to buy me a beer, just saying it makes me taste it

[Brian Lugo]

Homer Simpson: "Hhhmmmmmm Beeeeeerrrrrrrrrrrr"

[Jose Botella]

Does anybody knows why the Exception class doesn't behave to this respect as the rest of the checked exceptions?

[Valentin Crettaz]

Exception is the parent class of all checked exception but also of all unchecked exceptions.
Class Exception is not a checked Exception but just any exception (including runtime exception) that a program may want to catch...

[Rob Ross]

Actually, the way you should think about it is that ALL subclasses of Exception are checked, EXCEPT for RuntimeException and its subclasses.
The term "Checked Exception" is used a lot almost as if it were the exception to the rule, but in fact, most subclasses of Exception are checked.
ONLY RuntimeException and its subclasses are exempt from this, and are thus Unchecked.

[Jose Botella]

We need to catch or declare the Exception(s) we throw. The same as checked ones.

[Jose Botella]

Val I have found the following in JLS 11.2
The unchecked exceptions classes are the class RuntimeException and its subclasses, and the class Error and its
subclasses. All other exception classes are checked exception classes.

[Valentin Crettaz]

Yeah that's true , so ?
Oh, you mean that class Exception is a check exception ?
The problem is just that by catching Exception you may catch RuntimeException and not only checked exceptions.
[ February 08, 2002: Message edited by: Valentin Crettaz ]

[Jose Botella]

From your previous post
"Class Exception is not a checked Exception"

[Valentin Crettaz]

Jose,
as the code is
B myref = new B();
you do not need to catch any Exception since test is invoked on myref which is of class B and the compiler knows that method test in B does not throw any Exception.
If you change the code to
A myref = new B();
then the try-catch block is mandatory because method test of class A may be invoked, which confirms what you say and what I said before, namely, that all checked exception must be caught.
And if you keep
B myref = new B();
and invoke super.test() inside method test in class B then you also need the declare the throw clause in B.test and try-catch it in the main method.
[ February 08, 2002: Message edited by: Valentin Crettaz ]