How to add additional information to the exception object that can be retrieved later

[ouou]

In Java, I need to get the exact causes whether is FileNotFound or normal IOException. Which I mean if it is Filenotfound exception, do not loose the FilenotFound cause. If it is other IOException, show IOException. No overwritten the causes.

I need to accurately describe the problem,consolidate the exceptions

Important: I need the code block style in this required way.
The original code block must follow in this way, beyond this, no requirement
main(){
try {
readfile();
}catch {
}
}

readfile(){
try{...
}
finally{
if (br1 != null)
br1.close();
}
}

Above template cause a problem, in finally br1.close could possibly overwrite the FileNotException by generating a IOException.

Here is my complete code:

import java.io.BufferedReader;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;

class Hidden {
 String exceptionMessage=null;
  public static void main(String args[]){
    Hidden h = new Hidden();
        
    try {
     System.out.println("Main():: Try Block Starts");
     h.readFile();
     System.out.println("Main():: Try Block Ends");
    } catch (FileNotFoundException fne) {
     System.out.println("Main():: Catch FileNotFound Starts.");
     System.out.println("Hi, Caught FileNotFoundException!");
     System.out.println(fne.getMessage());
       //fne.printStackTrace();
    } catch (IOException ioe) {
     System.out.println("Main():: Catch IOException Starts.");
     System.out.println("Caught IOException!");
      System.out.println(ioe.getCause());
     //ioe.printStackTrace();
    }
  }
  
  @SuppressWarnings("finally")
public void readFile() throws FileNotFoundException,IOException {
   BufferedReader br1 = null;
      FileReader fr = null;
    
      try {
       System.out.println("readFile():: Try Block Starts."); 
       fr = new FileReader("data4.fil");                       //1
       br1 = new BufferedReader(fr);
       int i = br1.read();                                     //2
       //Other code...
       System.out.println("readFile():: Try Block Ends.");                                   //4
     } catch (FileNotFoundException e){
      System.out.println("readFile():: Catch Block Starts.");
      exceptionMessage="data1.fil is not exisited *****From Catch Block's Catch";
      throw new FileNotFoundException( exceptionMessage);
      
    }
     finally {
       System.out.println("readFile():: Finally Block Starts");
       try{ 
         System.out.println("readFile()::Try in Finally Block Starts.");
         fr = new FileReader("data1.fil");
         if (br1 != null) 
            br1.close();
        //throw new IOException();
       }catch (IOException ioe){
          System.out.println("readFile():: Catch in Finally Block Starts.");
           if(ioe instanceof FileNotFoundException){
            exceptionMessage+="\ndata1.fil is not exisited *****From Finally Block's Catch ";
            throw new FileNotFoundException(exceptionMessage);
           }else{
            exceptionMessage+="\nIO exception*****From Finally Block Catch";
            throw new IOException(exceptionMessage);
           }
       }  
        System.out.println("readFile():: Finally Block Ends");
      }
   }
}

.

[Fubarable]

I've edited your post to add [code] [/code] tags, but the pasted code is not formatted so they don't help. Please edit your post above and replace the unformatted code with well-formatted code so that others can read it without eye strain and with improved understanding.

[Junky]

Exception class has a constructor that takes a String parameter. You can add as much information to that String as you like. So you can catch your exception then rethrow your own exception with all the info that you need.

[ouou]

The problem is that "br1.close" in "finally" block could possibly generate an IOException, which overwrite the FileNotException generated from "try block" . Hence, lost the real reason. However, I am required to put br1.close in finally block, now i don't know how to solve my problem, to get the exact causes.

Exception class has a constructor that takes a String parameter. You can add as much information to that String as you like. So you can catch your exception then rethrow your own exception with all the info that you need.

[Junky]

If the FNFE is generated when trying to create the BufferedReader object then there will be no BufferedReader object to close.

[ouou]

Thank you, My question is that before the finally block, there might be a FNFE, what if inside the finally block, there is IOexception happens, it could be overwrite the FNFE. I want to clearly know in the finally block, if there is IOException occurs, I want it keep the original FNFE, not loose it. Can you give me any thoughts on that?thanks again.

If the FNFE is generated when trying to create the BufferedReader object then there will be no BufferedReader object to close.

[Junky]

Personally I would not be daisy-chaining exceptions together. A better solution would be to log each exception as they occur.

If you really must do this then you can save the exception to a local variable to use in the finally clause.

} catch (IOException ioe){
    if(ioe.getCause() instanceof FileNotFoundException);

First there is a semantic error in the above code.
Second do not do this. Catch the specific exception.

[Tolls]

The basic answer is, don't throw exceptions from a finally block.
Log them, but don't throw them.

And the reason for this is, as you've discovered, the finally exception will result in the original exception being hidden.
The original exception is the important bit, the stuff in a finally block should simply involve tidying up (releasing resources), something which, should it fail, should not result in a failure of that particular method. After all, it's a finally block, so the method should have finished doing what it needs to do by this point.

[Tolls]

Also, to echo Junky (to some extent):

    	 if(ioe.getCause() instanceof FileNotFoundException);
    	  throw new FileNotFoundException("data1.fil is not exisited");

Do not catch an exception and then throw a new one without chaining the source exception to it. You lose so much information (including the original stack trace) that you will curse yourself for doing this should you then try and find out where the exception came from. I have had to deal with code that does this and believe me it is evil.