Exception handling

[pratapsiva sivakumar]

Hi sir,
I am using a try{ some code} and then finall{some code} block.I am not using catch block.So if an exception is thron in try block,how to handle it.

[Fred Hamilton]

pratapsiva sivakumar wrote:Hi sir,
I am using a try{ some code} and then finall{some code} block.I am not using catch block.So if an exception is thron in try block,how to handle it.

I believe the way you are doing it is the same as catch( Exception e ) {...}, except you don't get an exception object to work with. So youhave to make up your own message.

[Filipe Pinheiro]

You should either declare or manipulate it inside of the caller method

   
public void doStuff(){
  try{
  }finally{
    //exception here
  }
}

//caller method
public void doStuff2()throws //exception{
     doStuff();
}

//or

public void doStuff2(){
   try{  doStuff(); }catch(//exception){}
}

 

[Fred Hamilton]

Filipe Pinheiro wrote:You should either declare or manipulate it inside of the caller method
...

Hold on. If anything ever gets thrown in that situation, that means my answer that a finally is like a catch without the exception object to work with must be wrong.

Filipe, do you see any possible value in having a try without a catch?

[Rob Spoor]

Any checked exception must either be caught or declared to be thrown. So if you don't catch it, throw it on:

public String readFile(File file) throws IOException // declare to throw
{
    Reader reader = new FileReader(file);
    try
    {
        StringBuilder sb = new StringBuilder(file.length());
        int c;
        while ((c = reader.read()) != -1) // can throw an IOException
        {
            sb.append((char)c);
        }
        return sb.toString();
    }
    finally
    {
        reader.close(); // put in finally so the Reader will always be closed
    }
}

[Fred Hamilton]

Thanks Rob for the example. I hadn't considered that there could be an exception other than that caused by a non-existent file.

I guess there might be a reason why you would want one or both exception types to be handled further up the stack, and still deal with closing the Reader within its scope. hence the try without a catch. Which means of course there is a reason for declaring the reader locally as opposed to passing the reader instead of the file name to this method.

regards.