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 e

Answer 1

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 2

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 3

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 4

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 5

The main Question is if it is a good idea to have methods returning Null at all, personally i do not have any problem with this, but as soon as you try to access modifiers of an object returned from this method and you forget to check if it is assigned this becomes an issue.

Ken has a good answer about this:

If you are always expecting to find a value then throw the exception if it is missing. The exception would mean that there was a problem.

If the value can be missing or present and both are valid for the application logic then return a null.

See this disscussion abou tthis issue:

Returning null is usually the best idea if you intend to indicate that no data is available.

An empty object implies data has been returned, whereas returning null clearly indicates that nothing has been returned.

Additionally, returning a null will result in a null exception if you attempt to access members in the object, which can be useful for highlighting buggy code - attempting to access a member of nothing makes no sense. Accessing members of an empty object will not fail meaning bugs can go undiscovered.

Some further reading:

• No Null Beyond Method Scope

• Should We Return Null From Our Methods?

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.