6

I am creating a new object 

myobject t = new myobject();

should I check on the next line for null reference , if the new succeeded ?

if (null != t)

or I can be sure that this object for sure will be different then null ...

Thanks.

Night Walker
  • 20,638
  • 52
  • 151
  • 228

5 Answers5

11

According to the C# documentation, if new fails to successfully allocate space for a new object instance, an OutOfMemoryException will be thrown. So there's no need to do an explicit check for null.

If you are trying to detect cases where new has failed to allocate a new object, you might want to do something like:

try {
    myobject t = new myobject();
    //do stuff with 't'
}
catch (OutOfMemoryException e) {
    //handle the error (careful, you've run out of heap space!)
}
aroth
  • 54,026
  • 20
  • 135
  • 176
  • Except that it isn't true; see my answer for a counter-example – Marc Gravell Apr 08 '11 at 11:14
  • 1
    But in your counter-example you acknowledge that "in any *sane* code, `new()` will never return a `null`". There are almost always obscure and esoteric cases that allow the rules to be arbitrarily subverted (for instance, maybe someone made a custom .NET runtime that has `new` randomly return `null`, just for kicks). But that wouldn't be sane, and an answer that holds true in any sane circumstances is good enough for me. – aroth Apr 08 '11 at 11:22
  • Well, maybe; but this is running in *regular* .NET framework, with no special hacks, plugins, libraries, configurations, etc... – Marc Gravell Apr 08 '11 at 11:26
  • 2
    Note that you can't really handle OOMException in newer versions of the CLR. You can handle it, but it just gets re-thrown automatically. It's essentially a fatal exception. – Eric Lippert Apr 08 '11 at 14:24
11

It really depends on how much you need to guard against pathologically stupid code ;p The following new() (against a class) will return null:

MyFunnyType obj = new MyFunnyType();

with:

class MyFunnyProxyAttribute : System.Runtime.Remoting.Proxies.ProxyAttribute {
   public override MarshalByRefObject CreateInstance(Type serverType) {
      return null;
   }
}
[MyFunnyProxy]
class MyFunnyType : ContextBoundObject { }

You do, thankfully, need to go a long way off-piste to get this type of crazy, though. In any sane code, new() will never return a null (except for Nullable<T>). Both these counter-cases are discussed more here.

But to reiterate: no, don't check the result for null unless you have reason to suspect somebody is being really, really daft.

Community
  • 1
  • 1
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
3

The new operator serves to allocate memory for a new instance of a class. Instantiating using new can, in "normal" scenarios (see Marc's answer for an edge case), never result in null, assuming memory is allocated successfully.

If object creation fails because its constructor threw an exception or memory can't be allocated, the code after that statement won't execute. So even if the object was null and you tried to check, the check doesn't happen. You would handle the exception instead using a try-catch block.

Community
  • 1
  • 1
BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
1

No, there is no point checking this.

David Neale
  • 16,498
  • 6
  • 59
  • 85
  • 2
    If you have to check its properties to see if you can act upon the object, I think that's a code smell. You have a constructor that can produce objects in an unusable state. – R. Martinho Fernandes Apr 08 '11 at 10:30
0

Skip the null check - the only case the object will not be created is the exception in constructor.

Unknown
  • 401
  • 2
  • 5