views:

1291

answers:

8

Give me some of your thoughts on which is a better coding practice/makes more efficient code/looks prettier/whatever: Increasing and improving your ability to use if statements to anticipate and catch potential problems? Or simply making good use of try/catch in general?

Let's say this is for Java (if it matters).

Edit: I'm presently transitioning myself away from some admittedly out-dated and constrained current coding practices, but I'm a little torn on the necessity of doing so on a few points (such as this). I'm simply asking for some perspectives on this. Not a debate.

+1  A: 

My 2p: Using try/catch is best:

  • it makes it absolutely clear to other coders that you are doing exception handling
  • the compiler understands what you are doing and can perform more appropriate compile-time checks for you

In my experience, using if-conditional-logic makes it more difficult to distinguish error handling from business logic.

Brabster
+3  A: 

If blocks are slightly faster, so if you arent going to need a dozen of them, theyre a better idea than try catches. Exceptions should be exceptional, not every time the code runs. I use Exceptions for rare events like server disconnections (even though they happen a few times every day), and if blocks for any of my controllable variables.

Karl
If/else is generally faster than try/catch, but it's slower than no code at all. If you have several levels of call depth, an if/else at each call site to propagate errors by return value is liable to be slower than a single try/catch at the top in the case where no error actually occurs.
Steve Jessop
+1  A: 

I think if statements are better. You can't surround every line of code with a try..catch (well you can but you should not do it). You can surround a block of code with try catch but not every line.

And exceptions slow things down.

Exceptions only slow things down when they're actually thrown. So as long as you ensure they're only thrown in exceptional circumstances (where performance usually no longer matters because you're going to fail), it's not a concern.
Steve Jessop
+2  A: 

Regardless of what code you're writing, you'll end up using both. I can't speak for the Java runtime, but on the .NET runtime there's a performance hit associated with the use of try-catch blocks. As a result, I try to use them only in areas where I've got a clear way to handle the exception once caught (even if it's just logging the existence of a problem).

If you find yourself using a lot of either try-catch blocks or if-else blocks in your code, or your methods tend to be rather long, consider refactoring the code into a larger number of smaller methods. The intent of your logic will be easier to follow--as well as easier to unit test.

Scott A. Lawrence
A: 

From what I've been told by more experienced developers and analysts, try/catch is more object oriented and if is more procedural.

I personally don't care.

I'm aware of the fact that a try/catch is slower and causes a performance hit, but if I'm going to use a dozen ifs to validate before I can do what I want to do, I will always use a try/catch to save on the number of lines of code.

It makes my life so much easier to not have to validate anything and if the statement fails, just do what I would have done in my 'else' block...in my 'catch' block.

Sometimes, I obviously enclose some if statements in a try/catch, but anyways.

I use an if when there's only a small number of things to validate (1 or 2) before doing what I need to do.

PersonalPerson
A: 

There's one thing that hasn't been mentioned here.

With an if-else statement, every time the code runs, at least 1 of the condition is guaranteed to be evaluated executed. I'm sure we all know how an if-else-elseif works, but to be clear... the if portion of the statement will always be evaluated, if it's false then the following else-if is evaluated, and so forth until only the else is left to evaluate.

So using an if-else statement will impact your performance. Not significantly (in most cases), but it does take CPU time to perform the evaluations.

try-catch statements, and correct me if I'm wrong, don't get considered at runtime until they're required (i.e. an exception is thrown). So simply wrapping your code in a try-catch will not affect performance until an exception is actually caught by it.

Also, it is not the catch that causes the performance hit, but the throw.

And one major point to make is, try-catch statements should NEVER be used for conditional logic. They should only be used for what they're designed for: exception handling!

Catching exceptions is essential, if you know what to do with them. If you have no way of properly handling the exception then you should let it go, for some code further up the chain may have a better way to handle it.

Its usually a good idea to have an exception hander at the absolute top level of your application to catch exceptions before they are seen by the user. In ASP.NET you can do this in the Application_Error event of the global.asax. In other languages/environments you would do so in your main loop, whatever that may be.

But note, there are some exceptions that are always best left uncaught. Sometimes when an exception happens it is an indicator that the state of your application has been severely compromised and cannot be trusted. The only safe thing to do is to kill and restart.

whatispunk
A: 

@PersonalPerson - Sorry, but this is just lazy coding. Rather than using a try-catch because there's too many if statements, why not refactor your code (i.e. put your validation logic in its own method). This will keep your code cleaner and more readable and maintain best practices for performance.

Never try to write your code to achieve the least # of lines. This will always end up badly. Sure you can find a more elegant way to write something that your coder-buddies will ooh and aah at, but it just makes things less readable.

I swear, I've worked with your code before, and it made my head hurt.

whatispunk