• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

two "try" OR one "try"

 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

#2 WAY

Thank You for your answer.
I'm sorry, my english is bad.
 
Ranch Hand
Posts: 193
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 1067
2
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
*/

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

Thank You.
Good luck.
 
Ranch Hand
Posts: 1140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 189
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic