Try Catch or If statement?

Question

if you think there is a possibility of getting a null pointer exception, should you use an if statement to make sure the variable is not null, or should you just catch the exception?

I don't see any difference as you can put your logic to deal with the null pointer in the if statement, or in the catch block, so which one is best practise?

Answer 1

There is no single answer that will suffice here, it depends.

Let's take a few scenarios so you can see what I mean.

Scenario: Method that takes a reference type parameter that does not accept null

You're defining a method, it takes a reference type parameter, say a stream object, and you don't want to accept null as a legal input parameter.

In this case, I would say that the contract is that null is not a valid input. If some code does in fact call that method with a null reference, the contract is broken.

This is an exception, more specifically, it's an ArgumentNullException.

Example:

public void Write(Stream stream)
{
    if (stream == null)
        throw new ArgumentNullException("stream");
    ...

I would definitely not just let the code execute until it tries to dereference the stream in this case, instead crashing with a NullReferenceException, because at that point I lost all ability to react when I know the cause.

Q. Why can't I return false instead of throwing an exception?

A. Because a return value is easy to silently ignore, do you really want your "Write" methods to just silently skip writing because you made a snafu in the calling code, passing the wrong stream object or something that cannot be written to? I wouldn't!

Scenario: Method returns a reference to an object, sometimes there is no object

In this case the contract is that null is a legal result. In my opinion, null is something to avoid because it is quite hard to make sure you handle correctly everywhere, but sometimes it is the best way.

In this case I would make sure to if my way around the result, to ensure I don't crash when the null reference comes back.

Generalisation

If you take a close look at the above two scenarios, you'll note one thing:

In both cases it comes down to what is being expected, what the contract is.

If the contract says "not null", throw an exception. Don't fall back to the old-style API way of returning false because an exceptional problem should not be silently ignored, and littering the code with if statements to ensure every method call succeeds does not make for readable code.

If the contract says "null is entirely possible", handle it with if statements.

Advertising

For getting a better grip on null problems, I would also urge you to get ReSharper for you and your team, but please note that this answer can be applied to any type of exception and error handling, the same principles applies.

With it comes attributes you can embed into your project(s) to flag these cases, and then ReSharper will highlight the code in question.

public void Write([NotNull] Stream stream)

[CanBeNull]
public SomeObject GetSomeObject()

To read more about the contract attributes that ReSharper uses, see

• ReSharper NullReferenceException Analysis and Its Contracts
• Contract Annotations in ReSharper 7

Answer 2

In my experience using if is better but only if you actually expect a null reference pointer. Without any bit of code or context its difficult to say when one option is better than the other.

There's also a matter of optimization - code in try-catch blocks won't be optimized.

Answer 3

From a performance standpoint it really depends what you're doing. The performance impact from a try/catch block when no exception is thrown is minimal (and if you really need that last few percent of performance, you probably should rewrite that part of your code in C++ anyway). Throwing exceptions does have a major impact on simpler operations such as string manipulation; but once you get file/database operations in the loop they're so much slower that again it becomes a trivial penalty. Throwing across an App Domain will have a non-trivial impact on just about anything though.

Performance in Operations/second:

Mode/operation               Empty   String      File   Database    Complex
No exception            17,748,206  267,300     2,461   877         239
Catch without exception 15,415,757  261,456     2,476   871         236
Throw                      103,456   68,952     2,236   864         236
Rethrow original            53,481   41,889     2,324   852         230
Throw across AppDomain       3,073    2,942       930   574         160

Additional test results along with the source for the tests is available from the article Performance implications of Exceptions in .NET

Answer 4

I would rather suggest you use if-statement for NullReference exception. For other exception, try-catch should be good enough.

The reason I suggest if-statement for NullReference exception is because C# will not tell which variable is null. if that line has more than one object could be null, you will loss track. If you are using if-statement, you can have better logging to help you get the enough information.

Answer 5

I would say ALWAYS use logic to catch the exception, not try/catch.

Try/Catch should be used when you validate but some strange thing happens and something causes an error so you can handle it more gracefully.

Answer 6

In general, try-catch blocks are great because they will break (move to the catch statement) whenever the exception occurs. If-else blocks rely on you predicting when the error will happen.

Also, catch blocks won't stop your code from halting when an error is hit.