Thorough use of 'if' statements or 'try/catch' blocks?

Question

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.

Solution 1

this debate (2003) was good:

http://www.joelonsoftware.com/items/2003/10/13.html

http://nedbatchelder.com/blog/200310/joel_on_exceptions.html

Solution 2

if blocks are slightly faster; if you aren't going to need a dozen of them, they're 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.

Solution 3

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.

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[Steve Jessop]

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.

[ThunderGr]

"Error Handling" and "Exception Handling" are not the same thing.

[ThunderGr]

How can you say that a try/catch is not considered at runtime until they are required? This sounds like some kind of programming magic. There is no such thing as code that is not considered until needed. You need to have at least a check whether it is needed or not.

[ThunderGr]

The answer of Steve above, to my comment, provides a reasonable explanation why a try/catch block would not be considered at all until an exception occurs. It does require a virtual machine to run on, though and it looks like the runtimes of the languages provide this virtual machine. I doubt the CPU architecture has any support for exceptions. Does it?

[Zachary Kraus]

Finally an answer on here that talks about effectively communicating ideas and making things easier to understand and code. I feel many of the answers on this site forget that important fact about coding and talk about code in a perfect world. These answers typically give best practice advice on either run speed or safety but don't take into account the question and whether that solution even makes sense to implement. Best practices are usually fast and easy, but in real software corner cases arise where these practices can become long and complicated; and simplification to the code are needed

[Zachary Kraus]

@ThunderGr I cant speak for all languages but mikesigs is correct at least for how C++ handles exceptions. In C++ the catch part of the block is ignored until an exception is thrown and the stack begins to unwind. As the stack unwinds, the code looks for a catch block to stop the unwind process. If none are found that are capable of excepting the exception. the program exits.

[Zachary Kraus]

Unfortunately this statement really depends on the language. In some languages having an if statement with many tests, like 6 or 10+ tests, where the if statement will be called 90+% of the time can take a lot of processor time depending on how the code is optimized. In this case using a try catch block will tell both the processor and other coders this is the code i want to run most of the time which can potentially increase run speed depending on the language. In any other case, I agree with you, unless your using a duck typed language such as python.

[ThunderGr]

@ZacharyKraus Where does it look for a "catch block" then, if not where I stated on my last comment here?

[Zachary Kraus]

@ThunderGr if you compile your code into assembly you can see there are two major things that contribute to exception handling __Unwind_Resume under a label statements and an except_table. These two areas of the assembly code work using the mechanism described on www.airs.com/blog/archive/464. Based on my simplistic understanding of that article, the exception handling is actually built into the compiled machine code and is called by jumping to the label where __Unwind_Resume is which begins both the exception handling process and the unwinding of the stack frame.

[Zachary Kraus]

@ThunderGr I think I might have made a slight error in the statement above. I think the order is slightly incorrect . The exception handling starts with the exception table and than I believe ends with Unwind_Resume. But that might also be incorrect as well.