2

I have some methods that return a value (or object) if all went as planned, otherwise return null (something went wrong).

For example, DataTable dt = DoSomething(); If something blew up in DoSomething() the return value would be null and dt would be set to null.

There are other cases where I'm testing for a value and then setting a variable to the value if the test value is not null. This doesn't feel right. I'm calling the same method twice.

For example, if (String.IsNullOrEmpty(getAddresss())) {Do Stuff;} If I declare a variable before the test, the code could blow up when it gets set. If I test, then set it seems like I'm duplicating work.

What is the preferred way to test for and handle null values?

DenaliHardtail
  • 27,362
  • 56
  • 154
  • 233
  • 2
    If something went wrong, it is usually better to just throw exception... – driushkin Mar 07 '11 at 18:06
  • I know this is not Java question, but Java is just 1 hop away from C#, so this does not matter. To solve this problem and problems related to this, Google employees have created `Guice 2`. Here is a into video, where thy explain the problems, how thy are solved and how `Guice 2` makes your life easier: http://www.youtube.com/watch?v=hBVJbzAagfs – Margus Mar 07 '11 at 18:37

6 Answers6

6

Throw exceptions from your methods instead of having them return null.

Regardless of where you stand in the almost religious arguments between return codes and exceptions, it's a fact that .NET is built on the premise of reporting errors by throwing exceptions. It would be really ill advised to follow a practice so detached from the rest of the framework for your code, if nothing else because of the unfamiliarity this will pose to others.

Jon
  • 428,835
  • 81
  • 738
  • 806
  • Totally agreed. Return codes for failed operations are infuriating because they seldom contain the rich amount of information available in an exception. – RQDQ Mar 07 '11 at 18:33
1

Is the duplication of work that important? It's all a null-check, after all (read: premature optimization).

I don't believe there's a shorter way, so just do the checks.

user541686
  • 205,094
  • 128
  • 528
  • 886
0

Another way to do this is to throw an exception in DoSomething(). That way, the actual reason for something blowing up can be logged, handled, passed on, etc.

RQDQ
  • 15,461
  • 2
  • 32
  • 59
0

Usually the coalesce operator (??) is pretty useful:

String myMessage = returnedValue ?? "Unspecified";

If the value being tested (returnedValue in this case) is not null, then it's returned; otherwise, the value on the right hand side of the operator is returned.

Here's the C# specification on the operator.

David Hoerster
  • 28,421
  • 8
  • 67
  • 102
0

Everything depend of the reason why the null is returned.

What you can do is:

  1. Use Null pattern
  2. throw an own Exception
Community
  • 1
  • 1
Damian Leszczyński - Vash
  • 30,365
  • 9
  • 60
  • 95
0

Code Contracts can help you in handling null values. Here's a short introduction http://devjourney.com/blog/code-contracts-part-1-introduction/

jimmystormig
  • 10,672
  • 1
  • 29
  • 28