Catching non-thrown exceptions

[Andreas Svenkson]

Hi guys, consider the following code:

import java.io.*;

public class TestFin {
	public static void main(String[]args) {
		try {
			System.exit(0);
		} catch (Exception e) {e.printStackTrace();}
		finally {System.out.println("finally");
		}
	}
}

This code compiles fine. The question I have is, if we change the catch-block argument to look for an IOException instead of an Exception, it will fail with the following msg:

TestFin.java:7: exception java.io.IOException is never thrown in body of corresponding try statement
} catch (IOException e) {e.printStackTrace();}
^
1 error

Now what I am wondering is basically what the mechanic/reason is that the compiler reacts with an error for IOException, but not Exception. I can imagine it is because the compiler somehow checks if the exception is a checked exception. If that's the case, I'd appreciate some insight how exactly it checks for it. Exception is ofcourse higher in the hierarchy, ruling out the possibility that the check is made by an "instanceof RunTimeException" test, and therefor does not give an error. So how does this check work/function?

// Andreas

[Shawn Smith]

Because System.exit() can throw a SecurityException, which can be implicitly down cast to an Exception. Nothing in the body of the try throws an IOException.

Cheers,
Shawn

[Ikpefua Jacob-Obinyan]

Shawn Smith wrote:Because System.exit() can throw a SecurityException, which can be implicitly down cast to an Exception. Nothing in the body of the try throws an IOException.

Hello Guys, @Shawn the above statement is NOT correct because with an EMPTY(without codes) try-catch block and an Exception as the catch argument the code still compiles, but when I changed it to known checked exceptions like; IOException, ParseException, InterruptedException etc including their corresponding imports, the code did NOT compile, I think Andreas ideas should be taken into consideration.

[Shawn Smith]

Fair statement Ikpefua. The Sun documentation states that the creation of an exception handler begins by having a try block with "one or more legal lines of code that could throw an exception". Since an empty try block doesn't meet that criteria, and there is nothing illegal about having an empty try block, you have to catch something. The compiler can evaluate all possible throws clauses for valid code, but lacking that can only handle the ultimate base class (that requires catching).

Since you can't have a try without a catch, and you can have an empty try block, you must allow the system to catch something.

If you do have "one or more legal lines of code that could throw an exception", you can only catch either Exceptions declared in the throws clauses of those lines, or their base classes.

Cheers,
Shawn

[Bear Bibeault]

Shawn Smith wrote:Since you can't have a try without a catch ...

Incorrect. A try can most certainly be written without a catch. There must be one of a catch block or a finally block, but the catch is not required.

[Andreas Svenkson]

Shawn Smith wrote:Since you can't have a try without a catch, and you can have an empty try block, you must allow the system to catch something.

Arguably.... the fact is you can have a try without a catch, if you use a finally, so I don't think what you're saying holds true.

It seems to be that it is always legal to catch RuntimeException, whether or not you invoke any code that might throw it. But if this is 100% true I don't know...

Shawn Smith wrote:If you do have "one or more legal lines of code that could throw an exception", you can only catch either Exceptions declared in the throws clauses of those lines, or their base classes.

I don't think this is the case. I think the following code shows that it's legal to catch things that cannot be thrown inside the try clause, which in this case only has a potential "IOException".

import java.io.*;

public class TestFin {
	public static void main(String[]args) {
		try {
			FileWriter fw = new FileWriter("out.txt");
		} catch (IOException e) {e.printStackTrace();
		} catch (ArithmeticException ae) {ae.printStackTrace();
		} catch (SecurityException se) {se.printStackTrace();
		}
		finally {System.out.println("finally");
		}
	}
}

We can guess several things from this, like "its always possible to catch RuntimeException", and "Exception is the only exception to this rule because an Exception can potentially be a RuntimeException" and so on. But does anyone actually know what's going on here and why?

// Andreas

[Boris Mechkov]

If you have an IOException for example and nothing that throws an IO exception, you get a compile error. A broad "Exception" can be caught for whatever reason (could be any kind of checked exception or even a programmer defined custom exception, even Runtime Exception), but a specific IOException (for example) is thrown by specific IO-based activities, defined in the Java API.

Another plausible explanation is that you can catch an "EXCEPTION" because the exception could be a Runtime exception that you want to handle. And since runtime exceptions are not checked they can be caught by just "catch (Exception e)"...

[Shawn Smith]

We can guess several things from this, like "its always possible to catch RuntimeException", and "Exception is the only exception to this rule because an Exception can potentially be a RuntimeException" and so on. But does anyone actually know what's going on here and why?

I suppose this makes sense since since RuntimeExceptions aren't required to be declared in throws clauses, so the compiler wouldn't be aware of them in the same way as Exception.

I was aware of the finally clause and was only trying to imply that try's have to be handled, and if java (for reasons beyond my understanding) allows for empty try blocks, it has to to provide some kind of hook to handle it gracefully.

Though if any of my developers ever show up with

try
{}
catch(Exception e)
{}

or

try
{}
finally
{}

to a code review, in the words of Ricky Ricardo, they'll have some 'splainin' to do.

Thanks for the debate, you folks are going to make me think real hard before typing

[Andreas Svenkson]

Let me try and clarify the questions of this thread.

1: Is it 100% true that you cannot try to catch ANY checked exception, unless you have invoked code that might throw it inside the try-clause?

2: Is it 100% true that you can always write code to catch any RuntimeException, whether or not you have invoked code that might throw it inside the try-clause?

3: Is there any other rule to this situation?

I'm pretty sure points 1 and 2 are true, but I'd like to have it confirmed. I also think that Throwable and Exception might be the only exceptions to these rules, since they can ofcourse always be a RuntimeException, but I'm just assuming here and you know what they say about assumption...

// Andreas

[Andreas Svenkson]

Shawn Smith wrote:Thanks for the debate, you folks are going to make me think real hard before typing

Hehe, you're not alone bro, I always try and think twice before posting to make sure im not shooting my mouth off too fast

// Andreas

[Ikpefua Jacob-Obinyan]

Hello Guys, This debate is very interesting!...@Andreas It looks like the puzzle continues! Now observe how 'Exception' behaves in the following program:

class Ikpefua {

  void go() throws Exception { }
  
    //void go2() throws RuntimeException { }

     public static void main(String[] args) {

         new Ikpefua().go(); 

        // new Ikpefua().go2 { } 
     }
}

Compilation FAILS at line 9 because the main method fails to comply with the decalre-or-handle obligation.
If you comment lines 3 and 9.....And uncomment lines 5 and 11 the code compiles and runs without problems.

Permit me add this question to yours: Why is 'Exception' behaving like 'non-checked' in a catch block and like
'checked' in a methods declaration?
For the purpose of the exam I think it is IMPORTANT to take note of this behaviour.

Shawn Smith wrote: Thanks for the debate, you folks are going to make me think real hard before typing

You are NOT alone bro, just like Andreas said, dont try to be perfect everyone here knows no one is above mistakes.

[Andreas Svenkson]

Ikpefua Jacob-Obinyan wrote:Hello Guys, This debate is very interesting!...@Andreas It looks like the puzzle continues! Now observe how 'Exception' behaves in the following program:

class Ikpefua {

  void go() throws Exception { }
  
    //void go2() throws RuntimeException { }

     public static void main(String[] args) {

         new Ikpefua().go(); 

        // new Ikpefua().go2 { } 
     }
}

Compilation FAILS at line 9 because the main method fails to comply with the decalre-or-handle obligation.
If you comment lines 3 and 9.....And uncomment lines 5 and 11 the code compiles and runs without problems.

Permit me add this question to yours: Why is 'Exception' behaving like 'non-checked' in a catch block and like
'checked' in a methods declaration?
For the purpose of the exam I think it is IMPORTANT to take note of this behaviour.

Shawn Smith wrote: Thanks for the debate, you folks are going to make me think real hard before typing

You are NOT alone bro, just like Andreas said, dont try to be perfect everyone here knows no one is above mistakes.

Interesting... My guess would be that the reason is fundamentally the same here, being that an Exception can be either a RuntimeException or a checked exception.

In my original question, we are always allowed to catch Exception and/or Throwable inside a catch-clause, even if, as far as we know, we haven't executed any code that throws them, due to the fact that they might possibly be a RuntimeException.

In this case, we are instead never allowed to let an Exception/Throwable go unhandled/undeclared for the very same, but reversed, reason: that they might possibly be a checked exception.

This is all my best-guess-reasoning though, if someone can confirm or explain it to be wrong, it is ofcourse appreciated.

// Andreas

[Tommy Delson]

Ikpefua Jacob-Obinyan wrote:Hello Guys, This debate is very interesting!...@Andreas It looks like the puzzle continues! Now observe how 'Exception' behaves in the following program:

class Ikpefua {

  void go() throws Exception { }
  
    //void go2() throws RuntimeException { }

     public static void main(String[] args) {

         new Ikpefua().go(); 

        // new Ikpefua().go2 { } 
     }
}

Permit me add this question to yours: Why is 'Exception' behaving like 'non-checked' in a catch block and like
'checked' in a methods declaration?
For the purpose of the exam I think it is IMPORTANT to take note of this behaviour.

If you go back to K&B Chapter 5 on exception and reread through you'll understand why. The fact is that RunTimeException or Uncheck Exception doesn't need to caught in try/catch block, the compiler doesn't care. It doesn't matter if you declared or handle the compiler won't give you a COMPILE ERROR like Checked Exception does if you don't declare or handle.

Note: The compiler doesn't ENFORCE the handle or declare RULES on the Unchecked or RunTimeException just like Error. Therefore, lines 5 & 11 compile without any problem vs lines 3 & 9.


----------

Consider this similar problem:

import java.io.IOException;

class AirPlane {
	public AirPlane() throws IOException, RuntimeException {
		System.out.println("AirPlane");
	}
}

class AirJet extends AirPlane { } // line 7

public class TesterException {
  public static void main(String args[]) throws IOException { // line 10
	new AirPlane(); // line 11
  }
}

What line do you see the problem and how do fix and make it compile?

[Ikpefua Jacob-Obinyan]

Hello Tommy,
thanks for your participation, I understand PERFECTLY everything you have explained, however you seem NOT to understand my question...So let me repeat it:

Why is 'Exception' behaving like 'non-checked' when used in a 'catch' PARAMETER and like 'checked' when used in a 'methods' DECLARATION?

P.S:In your code the problem is line 7. (I must admit that it is DIFICULT to spot) because the class Airjet has an implicitly placed default constructor that fails to comply with the obligation of handle-or-declare, this is how the class really looks 'behind-the-scenes':

class AirJet extends AirPlane { 
        public Airjet() { 
        super(); // Compiler error! caused by invocation of super class (Airplane) 
                     // constructor that declares 'checked' IOException
     }
} 

[Tommy Delson]

Why is 'Exception' behaving like 'non-checked' when used in a 'catch' PARAMETER and like 'checked' when used in a 'methods' DECLARATION?

@Ikpefua

Really I'm not quite fully understand your question, but I can address it based on what you asking.

I'm not quite sure what do you meant by "catch Parameter", but I think you referring to the try/catch clause. If so, the rule is if the calling method declared a Checked Exception then the caller of the calling method have to handle with try/catch block otherwise it will throws a COMPILE ERROR. However, you can DUCKING the Exception to the method the caller is in by declared or throws an Exception (i.e main()).

To make it clearly of what I meant see code before for illustration:

class Ikpefua {  
  
  void go() throws Exception { }  
    
    //void go2() throws RuntimeException { }  
  
     public static void main(String[] args) throws Exception {  //Main will handle the exception
  
         new Ikpefua().go(); 
//Ducking an Exception to main() by not provided try/catch block. If you don't want ducking the Exception then you can provide a         
//try/catch clause for the caller go() method.  

         
  
        // new Ikpefua().go2 { }   
     }  
}

To answer to your question "Why is 'Exception' behaving like 'non-checked' when used in a 'catch' PARAMETER", the fact it's NOT behave like unchecked exception simply because you didn't throw any Exception in go() method body therefore, when you invoke the method go() it just execute straight through because it found no Exception.

And "like 'checked' when used in a 'methods' DECLARATION", well the RULE is when you calling a method that declared an Exception you must provide a try/catch clause or Ducking the Exception. If you don't fulfill any of the those requirement the Compiler will complaints and throws a compiler error.


If you want to see the code behave like checked exception then try to throw an an Exception in the go() method.

Let put in coding and see if that make sense:

class TesterException {

  void go() throws Exception { throw new Exception(); } //Added a throw Exception

    //void go2() throws RuntimeException { }

     public static void main(String[] args) throws Exception {

         //Ducking Exception to main() so, you don't have to provide try/catch clause.
         new TesterException().go(); //Exception will throw in main() when you invokes go() here (i.e Exception in thread "main" java.lang.Exception)

        // new Ikpefua().go2 { }
     }
}

Hope I've addressed your question, if not be more specific so, I can address more.

Here is a little recap from K&B book: Suppose your method doesn't directly throw an exception, but calls a method that
does. You can choose not to handle the exception yourself and instead just declare it, as though it were your method that
actually throws the exception. If you do declare the exception that your method might get from another method, and you don't
provide a try/catch for it, then the method will propagate back to the method that called your method, and either be caught
there or continue on to be handled by a method further down the stack.


--------------------------
P.S:In your code the problem is line 7. (I must admit that it is DIFICULT to spot) because the class Airjet has an implicitly placed default constructor that fails to comply with the obligation of handle-or-declare, this is how the class really looks 'behind-the-scenes':

class AirJet extends AirPlane { 
        public Airjet() { 
        super(); // Compiler error! caused by invocation of super class (Airplane) 
                     // constructor that declares 'checked' IOException
     }
} 

Very good, you spotted the problem and I think you know how to fix it by now.

NOTE: Try some examples of Exception in method overriding and polymorphism, you'll encounter some of those on the Exam.

[S Thiyanesh]

The reason that "Exception" is allowed in the catch clause is "Any runtime exception is a subclass Exception" and we are handling the broader exception.
We are not allowed to catch "IOException" if none of the enclosing code block can cause "IOException", since no RuntimeException is subclass of the "IOException".

Thanks,
Thiyaneshwaran S

[Ikpefua Jacob-Obinyan]

Hello Tommy,
thank very much for your time taken explanation...Im afraid you still dont understand my question, however your effort to explain is sincerely appreciated. I know 'practically' everything that my knowledge could be tested on about exceptions in the exams. I want to use codes to ask you the question so you can finally understand what I mean.

Why is 'Exception' behaving like 'non-checked' when used in a 'catch' PARAMETER // and like 'checked' when used in a 'methods' DECLARATION?

Now lets divide this question into two using small programs to demonstrate observe CAREFULLY:

1.Why is 'Exception' behaving like 'non-checked' when used in a 'catch' PARAMETER?

import java.io.IOException;

class MyClass {
    void go(){
        try{
        //nothing here
        } catch (Exception e){ // Compiles!!...compiler considers that
                                   // 'Exception' is NOT 'checked' why??? }
    }
  }
}
class MyClass2 {
    void go(){
        try{
        //nothing here
        } catch (IOException e){ // Compilation fails!! compiler considers
                                      // that 'IOException' is 'checked' understood }
    }
  }
}

Since 'Exception' is 'Checked' why did the compiler NOT complain?
Since 'IOException' is also 'Checked' why did the compiler complain?

And be informed that all other 'Checked' exceptions do NOT compile
in this scenario.
_____________________________________________________________________________

2.and like 'checked' when used in a 'methods' DECLARATION?

import java.io.IOException;

class MyClass3 {
   void go()throws Exception { }
      public static void main(String[] args){
         new MyClass3().go(); //Compilation fails!! compiler considers
                                   // that 'Exception' is 'checked' why???
   }
}
class MyClass4 {
   void go()throws IOException { }
      public static void main(String[] args){
         new MyClass3().go(); //Compilation fails!! compiler considers
                                   //that 'IOException' is 'checked' understood.
   }
}

Summary:

1. 'Exception' is NOT 'checked' in a 'catch' PARAMETER
2. 'Exception' IS 'checked' in a methods DECLARATION

Why???

[Ikpefua Jacob-Obinyan]

S Thiyanesh wrote:The reason that "Exception" is allowed in the catch clause is "Any runtime exception is a subclass Exception" and we are handling the broader exception.

Hello Thiyanesh...I understand better now, it means the compiler is aware that if there's any runtime 'checked' exception, it will ALWAYS be a subclass of 'Exception'.

However in a methods DECLARATION the scenario is different, we are saying in effect: "a 'checked' exception will be thrown", therefore an invocation of the method is 'compromised' to 'handle-or-declare'.

I hope my analysis is correct...Can you please confirm that? I will appreciate.

Regards

Ikpefua.

[Shawn Smith]

The below is from the jvms (http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#3129). It almost seems to imply that the examples illustrated shouldn't compile, but maybe someone else can correct my interpretation. The other thing I found interesting was that the JRE does nothing to enforce the rule, so through some devious bytecode manipulation you could probably do some funky stuff.

A method should throw an exception only if at least one of the following three criteria is met:

* The exception is an instance of RuntimeException or one of its subclasses.

* The exception is an instance of Error or one of its subclasses.

* The exception is an instance of one of the exception classes specified in the exception_index_table just described, or one of their subclasses.

These requirements are not enforced in the Java virtual machine; they are enforced only at compile time.

To try to do a deeper dive I've been playing around with javap. In the VM spec there's an example of what's generated through a piece of code with try/catch block that looks like

Compilation of try-catch constructs is straightforward. For example,

void catchOne() {
try {
tryItOut();
} catch (TestExc e) {
handleExc(e);
}
}

is compiled as

Method void catchOne()
0 aload_0 // Beginning of try block
1 invokevirtual #6 // Method Example.tryItOut()V
4 return // End of try block; normal return
5 astore_1 // Store thrown value in local variable 1
6 aload_0 // Push this
7 aload_1 // Push thrown value
8 invokevirtual #5 // Invoke handler method:
// Example.handleExc(LTestExc;)V
11 return // Return after handling TestExc
Exception table:
From To Target Type
0 4 5 Class TestExc

With the empty try/catch in a main method, I get something like

public class SomeClass
{
   public static void main(String [] args)
   {
       try
       {} 
       catch(Exception e)
       {}
   }
}

  public Main3();
    Signature: ()V
    flags: ACC_PUBLIC
    LineNumberTable:
      line 1: 0
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0       
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return        
      LineNumberTable:
        line 1: 0

  public static void main(java.lang.String[]);
    Signature: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    LineNumberTable:
      line 8: 0
      line 9: 3
    Code:
      stack=0, locals=1, args_size=1
         0: goto          3
         3: return        
      LineNumberTable:
        line 8: 0
        line 9: 3
      StackMapTable: number_of_entries = 1
           frame_type = 3 /* same */

Which makes it look like the compiler is just optimizing the exception out and ignoring it completely. In order to confirm what I was seeing I threw in something that has a legitimate throw

public class Main3
{
  public static void main(String [] args)
  {
    try
    {
      Thread.sleep(100);
    }
    catch(Exception e)
    {}
  }
}

Which results in:

  public static void main(java.lang.String[]);
    Signature: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    LineNumberTable:
      line 7: 0
      line 10: 6
      line 9: 9
      line 11: 10
    Code:
      stack=2, locals=2, args_size=1
         0: ldc2_w        #2                  // long 100l
         3: invokestatic  #4                  // Method java/lang/Thread.sleep:(J)V
         6: goto          10
         9: astore_1      
        10: return        
      Exception table:
         from    to  target type
             0     6     9   Class java/lang/Exception
      LineNumberTable:
        line 7: 0
        line 10: 6
        line 9: 9
        line 11: 10
      StackMapTable: number_of_entries = 2
           frame_type = 73 /* same_locals_1_stack_item */
          stack = [ class java/lang/Exception ]
           frame_type = 0 /* same */

Line 16 and 17 show that the exception is recognized and has the handle set up.

I don't know if this answers any questions, but hopefully it's some useful additional information.

Cheers,
Shawn

[Tommy Delson]

Your Question: 2.and like 'checked' when used in a 'methods' DECLARATION?

Regards to this problem I've provided the reason why it give you a COMPILATION FAIL. I
think you MISUNDERSTOOD the concept of exception being declared in methods and handle in
try/catch block. Correct me if I'm wrong...

Again, the RULE is when you calling a method that declared an Exception you must provide a
try/catch clause or Ducking the Exception. If you don't fulfill any of the those requirement
the Compiler will complaints and throws a compiler error.

Let's put in coding and see if it makes sense:

import java.io.*;

public class TesterException {

   void go()throws Exception { } //You declared a throws Exception on go() method

   void go2()throws IOException { } //You declared a throws IOException on go() method

      public static void main(String[] args){

		 try{ //Provide a try/catch clause when calling the go() method simply because earlier
		 	  //you have declared a throws Exception on the method. You you don't provide 
                          //try/catch clause you can DUCKING it by declare on main() method.

			//This call will fail if you not provide or wrap with a try/catch clause
         	new TesterException().go(); //Compilation fails!! compiler considers

         }catch(Exception e){ // that 'Exception' is 'checked' why???

			 e.printStackTrace();  //Output goes to System.err.
		 }


		 try{ //Provide a try/catch clause when calling the go2() method simply because earlier
		 	  //you have declared a throws IOException on the method. You you don't provide 
                          //try/catch clause you can DUCKING it by declare on main() method.

			//This call will fail if you not provide or wrap with a try/catch clause
         	new TesterException().go2(); //Compilation fails!! compiler considers
                                      //that 'IOException' is 'checked' understood.

	 	}catch(IOException io){

			 io.printStackTrace();  //Output goes to System.err.
		}


   }


}

//-------------------------------


Your Question: 1.Why is 'Exception' behaving like 'non-checked' when used in a 'catch' PARAMETER?

Check out: In K&B book check out topic "Handling an Entire Class Hierarchy of Exceptions" for more info

import java.io.*;

class TesterException {
    void go(){
        try{
        	//nothing here

        } catch (Exception e){ //You could even set up an exception handler that handles any Exception with the handler here
        						//A (too) general exception handler

			// Compiles!!...compiler considers that
            // 'Exception' is NOT 'checked' why??? (Don't misunderstood checked and handler exception are totally different)



          /*

          	"The Exception class is close to the top of the Throwable class hierarchy. Therefore, this
          	handler will catch many other exceptions in addition to those that the handler is intended
          	to catch."

          	The reason the Compiler allows the argument type Exception declared in the catch parentheses
          	because, an Exception class's the superclass in your catch clause. That means any Exception
          	throw in the try clausse will be caught by the Exception. In other words, broader or general
          	exception that specified in the catch clause.

          	Reread the book on section "Handling an Entire Class Hierarchy of Exceptions" for more info.


          	A recap from K&B book: This code will catch every exception generated. Of course, no single
          	exception handler can properly handle every exception, and programming  in this way defeats
          	the design objective. Exception handlers that trap many errors at once will probably reduce
          	the reliability of your program because it's likely that an exception will be caught that
          	the handler does not know how to handle.


          */

   		}

	}



    void go2(){

	        try{
	        //nothing here

	       		//throw new IOException(); //Throw an IOException

	       		throw new FileNotFoundException(); //Throw an exception Subclass of IOException. Will compile if you provide a 
                                                                           //throw an exception that is subclass of IOException.

			}catch (IOException me){ // Compilation fails!! compiler considers

			/*

			  "In most situations, however, you want exception handlers to be as specific as possible.
			  The reason is that the first thing a handler must do is determine what type of exception
			  occurred before it can decide on the best recovery strategy."

			  A method can write specific handlers that can handle a very specific exception.
			  The FileNotFoundException class has no descendants, so the following handler
			  can handle only one type of exception.

			  catch (FileNotFoundException e) {...}


    		  The reason the Compiler fails simply because, there is NO throw statement in the try
    		  clause. Since you didn't specify throw exception so, it won't compile.

    		  In this scenario IOExceptioin is superclass of FileNotFoundException exception so, it
    		  can handles any exception thrown from it SUBCLASS in this case FileNotFoundException or
    		  other subtype.

    		  Again, why it allows Exception to declared in the catch clause without any exception
    		  thrown in the try clause?

			  Again this is simply because an Exception is superclass of all exception and broader or
			  general to catch all exception. However on the go2() method you needs to specify a throw
			  statement in a "try" clause so,the "catch" clause can catch the exception of it type or subtype.

			  IOException needs more specific exception above it so, when you compile it will throws an error
			  if you're not specify ONE such as:

			  TesterException.java:43: exception java.io.IOException is never thrown in body of corresponding try statement
			                  } catch (IOException e){ // Compilation fails!! compiler considers
			                    ^1 error


    		*/

    		}
	}

}

[Ikpefua Jacob-Obinyan]

Tommy wrote: Regards to this problem I've provided the reason why it give you a COMPILATION FAIL. I think you MISUNDERSTOOD the concept of exception being declared in methods and handle in try/catch block. Correct me if I'm wrong...

Hello Tommy,
again I want to express my appreciation for your effort in explaining these concepts, however if you NOTICED the last statement/s I made you will see that I agree with you and understand the concepts very well.

I was ONLY wondering why one is NOT 'obliged' to provide code that may result in an exception being thrown, when 'Exception' is used in a 'catch' PARAMETER, and in effect 'obliged' to handle-or-declare by a methods CALLER when 'Exception' is added to a methods declaration.

I know everything that is REQUIRED about exception for the purpose of the exams AND I understand these concepts better THANKS to you all.

Regards

Ikpefua.

[Tommy Delson]

Ikpefua Jacob-Obinyan wrote:

Hello Tommy,
again I want to express my appreciation for your effort in explaining these concepts, however if you NOTICED the last statement/s I made you will see that I agree with you and understand the concepts very well.

I was ONLY wondering why one is NOT 'obliged' to provide code that may result in an exception being thrown, when 'Exception' is used in a 'catch' PARAMETER, and in effect 'obliged' to handle-or-declare by a methods CALLER when 'Exception' is added to a methods declaration.

I know everything that is REQUIRED about exception for the purpose of the exams AND I understand these concepts better THANKS to you all.

Regards

Ikpefua.

You're welcome....I see your POINT, but I need to consult with Oracle/Sun and those invented Java for insight why they allowed such things happen. I'm sure there are reasons behind that. Probably we need to dig more in the documentation to find out or check out with Oracle/Sun for the WONDERING.

Peace...

[Oliver Rutishauser]

My workaround is different. It is quite obvious that the compile is wrong. (Otherwise this question hasn't been asked here.) So to make it work the way I want it to work, I have created the following function.

public void javaBug() throws UnknownHostException { }

and call it from the corresponding try block. Now the compiler is happy.

[Stephan van Hulst]

Welcome to CodeRanch!

What do you think the compiler is wrong about? And in what kind of situation would you need a workaround like that?

[Oliver Rutishauser]

I have restarted my application, so the actual output is lost. But the whole story is the following. I use a library to access a web service. The application worked fine, so I left it running for the weekend. On Monday I have discovered that something was temporary wrong with the network, and the library failed to resolve the host name for a couple of times. The error caused the stack trace to dump. I decided that this error is essential for my application and I need to handle the exception gracefully. To my surprise, when I added an appropriate catch block, the compiler refused to compile my application. I believe that I am the boss here, and I am to decide which exceptions should be handled and which should not. I do not want to handle all the unchecked exceptions.  

[Tim Holloway]

You cannot code a catch for a checked exception unless one or more methods invoked in the try block was declared as throwing that exception.

The essence of checked exceptions is that their usage is explicitly stated. The compiler sees that none of your code includes methods that throw that exception and tells you you're being an idiot. It's not going to waste its time dealing with something that's provably not possible.

If you want sloppy compilers, use one of the scripting languages so beloved of managers who'd rather get stuff fast than get stuff correct. Java wasn't designed for that, and if you think you're the one in control here, well...

[Stephan van Hulst]

As Tim pointed out, when the compiler tells you its an error to try and catch some sort of exception type, it means that exception type will never reach the part of the code where you're trying to catch it. So while your workaround will force the scope where you call that method to throw an exception of your expected type, that exception will not be the actual cause of your problem, nor will it even be the actual exception type that the REAL exception has.