What's better/faster? Try-catch or avoid exception?

Question

I would like to know, what's better or/and faster in general programming? Avoid the exception or wait for the exception?

Avoid the exception would be:

string a = null;
list = someMethod();
if(list.Length > 0 ){
   a = list[0];
}
if(a!=null) ...

Or try catch exception...

string a = null;
try{
    a = someMethod()[0];
catch{}
if(a!=null) ...

Answer 1

Performance is not the most relevant concern here. The question is, which of the two leads to more readable/maintainable/testable programs. You can worry about performance later.

In general, don't use exceptions for flow control. They are effectively a non-local goto which makes programs more difficult to read and follow. As such, they should be reserved for exceptional situations. If you can get away with not using a try-catch block for flow control, don't. Your programs will be more readable and maintainable.

The "right" way to handle this situation is

var list = someMethod();
if(list == null || list.Length == 0) {
    // handle something bad
}
string a = list[0];
if(a != null) {
    // go
}

You can avoid the check that list is not null and not empty if there is a contract ( Contract.Ensures ) that guarantees the return value from someMethod is not null and not empty.

It is true, however, that exceptions are locally expensive. Whether or not they will impact the performance of your program (ie, are a bottleneck) is another question altogether. But used properly, exceptions are generally not a bottleneck (who cares about performance when your application is crashing?)

Answer 2

Exceptions are expensive - if you can test and avoid the exception, do so.

Exceptions should not be used for normal program flow.

Answer 3

当然要避免异常，尝试捕获会导致性能下降。

Answer 4

It depends. I almost always try to avoid the exception unless doing so is prohibitively costly.

Answer 5

Purely from a number of instructions / performance standpoint over a significant N runtime, avoiding is more expensive, because you're checking the length every time for every input. With an exception, the catch branch is only executed on that eventuality.

Answer 6

ALWAYS ALWAYS ALWAYS avoid an exception if you can.

Exceptions should be exceptional.

If you can predict it, protect against it happening.

People who use empty catch blocks like that should be banned from using a computer...

It's also faster to not go into catch blocks.

Answer 7

Throwing exceptions is an expensive task, so I would always try and validate rather than catch.

This should be easy enough to test, generate some code that throws an exception through each run and test it against a similar set of code that does conditional checking and measure the performance.

If the code is documented with details of which conditions exceptions will be thrown, you should be able to adapt your calling code. Of course you can't handle every scenario (lower level runtime errors perhaps?), so your code should only really try and handle exceptions where it can actually react and possibly continue.

Answer 8

Exceptions should only be used for exceptional conditions (unless there's no alternative), so you should only use try/catch when there's something highly unusual going on that you still need to deal with (pop up an error message).

Having a try/catch also signals to a programmer that some external error might happen and needs to be dealt with. In your example, list being null is simply a normal part of program execution/control flow, and so there's nothing exceptional about it.

Also, an empty catch-all is generally a bad thing to have anyway (although there are limited situations where it's needed). It should certainly need a comment anyway to explain why you're not doing anything about the exceptions.

There's a useful blog post about vexing exception you might find useful