This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

try/catch best practice  RSS feed

 
Fritz Urling
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ok, suppose i'm doing somethine like

int i = Integer.parseInt(myString);

now, i know this can throw a NumberFormat exception. i probably want to catch that, so the program doesn't blow up.

so i write this:


ok so this seems to work. but my question comes here.... if the parseInt works, i want to do (potentially) a bunch of stuff. should i put all that stuff in the try block? or should i set a flag, then once i'm out of the whole try/catch block, test my flag to see if i should do the rest of the porcessing?

if i put all the code in the try block, then potentially my entire program is in there. yes, i can abstract it into a few other methods, but still... that just seems wrong to me.

on the other hand, setting a flag in the try block and testing later sort of seems like an end-run to me. i kind of feel like i'm defeating the purpose of the try/catch. or am i?

i'm just wondering what the "best practice" is, if it exists.
[ April 20, 2006: Message edited by: Fritz Urling ]
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are a couple of options, you could put the try catch into a while block and keep propmting for re-entry until you get good data.



You will also get those who will tell you its bad practice to catch any RuntimeException, and that you shouldn't rely on a catch block to do input verification. To satisfy that crowd you could write a method to do the input checking and eliminate the try/catch all together.


[ April 20, 2006: Message edited by: Garrett Rowe ]
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A final thought, if args[0] is actually a command line argument to a main() method, then re-prompting for good data is probably not an option. In that case you options are reduced to printing out an error-message, and returning form the method.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Putting the whole body of a method into a try block, with catches at the end, is actually considered a good practice by some; this concentrates the error handling in an out-of-the-way place, and lets you see more clearly what the flow of the method is intended to be. Of course, I also believe -- and many more people agree with me on this one -- that methods should be as short as possible: less than ten lines almost always, less than five if possible.
 
Rusty Shackleford
Ranch Hand
Posts: 490
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that methods should be as long as they need to be. If you restrict it to some arbitrary number, the amount of method calls(very expensive) grows quickly.

I think a method should do 1 basic task. It might be short, but it could take a bit. Breaking up a basic task is generally a bad idea IMO. A basic task is one that can not be logically broken up into two or more tasks.

Anywho, using try/catch blocks to catch runtime exceptions is fine. Just use them logically.

If you use multiple try/catch blocks, things can get ugly, especially with nested try/catch blocks. The thing to remember is that a try block can have as many catch blocks after it as you like, but you have to remember exception precedence. Put a catch SocketException right after a catch IOException and the compiler will complain that the SocketException is already caugh in the IOException.

The only time I use multiple try/catch is when I have several lines that could throw the same exception and I need to do something different for each one.
 
Justin Fox
Ranch Hand
Posts: 802
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Methods can be extremely long, especially if you do graphics methods...

say want to draw a certain object, sometimes it can be pretty long, and

many draw this and draw thats...

if your methods get what you need done, then its a good method eh?

there may be a more efficient way, but as long as it gets you an A

who cares!

-Justin-
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Justin Fox:

there may be a more efficient way, but as long as it gets you an A

who cares!


:roll:
 
Henry Wong
author
Sheriff
Posts: 23283
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with EFH, in that methods should be short. In fact, I try to fit all my methods on the screen. If you can't see the whole method at the same time, it may be two long.

Now, of course, there are exceptions to this rule. There are cases, where it just makes sense to have a long methods -- particularly when the execution is a linear, without many reusable blocks. However, in these cases, it is highly documented. And organized for readibility.

Henry
[ April 20, 2006: Message edited by: Henry Wong ]
 
Fritz Urling
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sounds like i've got a religious war starting here. Sorry.

But thanks for the advice.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!