two "try" OR one "try"

[dar]

Hi ranchers.
Could You me describe this "problem".
In my code I need caught two different exception: "IOException" and "InterruptedException".
There are two way. (see below)
Which way is better ? Which way faster and need less "memory"?
#1 WAY

try{
   ........................ //LINE #1
   obj.First()   //this method throws "IOException"
   ........................
   ..... some codes .......
   ........................
   obj.Second()   //this method throws "InterruptedException"
   ........................
   ........................ //LINE #87
}
catch(IOException ioerr){
   ........................
}
catch(InterruptedException ioerr){
   ........................
}

#2 WAY

   ........................ //LINE #1
try{
   obj.First()   //this method throws "IOException"
}
catch(IOException ioerr){
   ........................
}
   ........................
   ..... some codes .......
   ........................
try{
   obj.Second()   //this method throws "InterruptedException"
}
catch(InterruptedException ioerr){
   ........................
}
   ........................
   ........................ //LINE #87

Thank You for your answer.
I'm sorry, my english is bad.

[Graeme Brown]

Originally posted by dajac chison:
Which way is better ? Which way faster and need less "memory"?

That is not important. The logic is different between the two ways.
In #1 way the second method will not be called if the first method throws an IOException.
However in your #2 way the second method will be called whether or not the first method threw an Exception.
You need to decide what behaviour you want. For example if you want to open and read from a file, there is no point in calling read if the open threw a FileNotFoundException so #1 would be appropriate. In other situations #2 would be better.
Your English is quite understandable, no need to be sorry.

[William Barnes]

However in your #2 way the second method will be called whether or not the first method threw an Exception.

Not if he throws out of the catch.
But you basic point is valid, in that if the catch doesn't throw the logic of the program would be different.
I would be included to use #1. It makes the code easyer to read, and keeps the code which will be executed, in normal times, together. You can always add comments to the catch telling how execution got there.

[dar]

Thank You for your answers. They help me.
Now I have similar question.
There are two ways(below).
Which one do you prefer? Why ?
Way #1:
/*
in this case ALL code (whole method) is in "try" block
*/

testMethod() throws out_Exception{
 try{
   ..... // the first line
   .....
   .....
   .. // here could throw in_ExceptionB ?
   .....
   .....
   ..... //the last line
 }
 catch(in_ExceptionB eb){
   ......
   throw new out_Exception(eb.getMessage());
 } 
}

Way #2:
/*
in this case ONLY PART of code (NOT whole method) is in "try" block
*/

testMethod() throws out_Exception{
 .....//the first line
 .....
 .....
 try{
   .. // here could throw in_ExceptionB ?
 }
 catch(in_ExceptionB eb){
   ......
   throw new out_Exception(eb.getMessage());
   // ----- don't continue -----
 } 
 .....
 .....
 .....//the last line
}

Thank You.
Good luck.

[Mani Ram]

On first look, way #2 looks as good as way #1
But, say you implement way #2. Tomorrow you modify the code so that your second line might throw an exception. How are you going to handle it?
Will you add another try/catch block for the second line alone or will you increase the scope of thee existing try/catch block so that it covers the second line also?
Having multiple try/catch blocks is probably redundant. I would prefer to go for way #1. But ofcourse, it all mainly depends on the logic as Graeme Brown pointed out.

[Philip Shanks]

I prefer #1, as it keeps related code together and makes it more readable. But as Graeme pointed out, when the first method bails, the second won't called.
You didn't include any info on the relative priority of these methods, so I can't comment on the desired behavior.
However, if the second method is so important that it should run regardless of the outcome of the first, then perhaps you should consider using the third part of the construct, and put it into a finally block.
Personally, I avoid splitting up related pieces of code into separate try/catch constructs, but that's a stylistic preference on my part.
PCS

[Mani Ram]

Originally posted by Philip Shanks:
but that's a stylistic preference on my part.
PCS

Not actually I think.
Usage of try/catch blocks requires boundary checks at runtime. It might affect the performance if you have multiple try/catch blocks.
Any other opinions?