File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes try and catch code (please comment) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "try and catch code (please comment)" Watch "try and catch code (please comment)" New topic

try and catch code (please comment)

mark stone
Ranch Hand

Joined: Dec 18, 2001
Posts: 417
below is an example from KM book that shows
how various try and catch blocks have been
used. (example 18.2 page 559).
and below that is how i have modified the
code with just one try block. is my approach ok ?
my code works fine though. but wanted to know if
this approach is ok. or both approaches are ok ?
what are the pitfalls with the second approach ?
fromFile = new FileInputStream....
toFile = new FileOutputStream.... }
int i =}
toFile.close... }
This is how i have modified the code with
one try block only. code works fine though.
fromFile = new FileInputStream....
toFile = new FileOutputStream....

int i =}

toFile.close... }
catch(FileNotFoundException e){System.out.println(e);}
catch(IOException e){System.out.println(e);}
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
Well i am not any experienced developer.But when i goes through this e.g i coded as the second one.I dont think that 1st one makes any special sense.Rather LCO's in 2nd are less.Which i usually prefer when programming.

Count the flowers of your garden, NOT the leafs which falls away!
Prepare IBM Exam 340 by joining
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1873
well mark,
i would say its just a programming style. but it might be useful to devide things like KM has done as u might in future, while upgrading or extending the code, want that u have separate methods doing each logical task - opening file (may be the code opens more than one file or does some extra processing before opening file), performing read/write etc operations (this may be extended to formatting the input, store it somewhere in formatted manner et), finally closing down all things smoothly..
at that time u can just copy and paste the code with try and catch to the method u want.
again, one can argue that, that can be done even if we don have this kind of separation. but yeah..thats a valid argument.
this is just a way of programming and reflects ur thinking process. if u can think in terms of task separation and objects/methods, it will help u in other places i guess.
the same argument i have about using getter/setter methods sometimes (if u know what i mean) as methods are definitely OVERHEAD because method call takes time/resources and sometimes i find useless/cumbersome to write a method for each damn private variable in the class...but ppl prefer that and call it "component based BEAN development" so i do it.
we can be probably better answered on some "optimization/performace/designing/codingstyle suggestions forum" well about this may be. me too is not so much exprienced programmer so to say.
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
The first approach has an advantage. The code that react to the exception is much more easy to write, because is splitted in several catch clauses placed after the specific code spawning the problem.
However correcting code in the second approach has to be able to consider if IOException (for instance) was launched by read or close.

SCJP2. Please Indent your code using UBB Code
chi Lin
Ranch Hand

Joined: Aug 24, 2001
Posts: 348
Personally, I believe the obvious advantage for the 1st coding style is that when exception indeed being thrown, you will have more clues which part went wrong (open, read, close..).
So it is sort of defensive coding for debugging purpose.
I agree. Here's the link:
subject: try and catch code (please comment)
It's not a secret anymore!