Not creating an instance

[tshad]

I am trying to create a class that may have an error in the constructor.

For example:

using System;

public class Demo
{
public Demo ()
{
Some code that reads database and fails for some reason
}
}

If the constructor fails, is there a way to just return a null object?

Such that I could write:

Demo theDemo = new Demo()
if (theDemo == null) then ...

Thanks,

Tom

 

[Bruce Wood]

No there is not.

You have to throw an exception.

 

[Kent Boogaart]

And it's bad practice to do any substantial work in your constructor. It's
nasty to have constructors throw exceptions too. I would recommend just
*constructing* in your constructor and putting the meaty work into a
separate method.

HTH,
Kent

 

[Flo 'Irian' Schaetz]

If the constructor fails, is there a way to just return a null object?

Such that I could write:

Demo theDemo = new Demo()
if (theDemo == null) then ...

You could simply try making the constructor private and using a static
method to call it (and do the "dirty" work which could fail):

private thingy() {
//... construct it
}

public static thingy createThingy() {
thingy t = new thingy();
// ... make dirty things with it.
if ( /* failure */) {
return null;
}
return t;
}

 

[Jon Skeet [C# MVP]]

And it's bad practice to do any substantial work in your constructor. It's
nasty to have constructors throw exceptions too. I would recommend just
*constructing* in your constructor and putting the meaty work into a
separate method.

It's not particularly nasty to have constructors throwing exceptions in
..NET. It causes difficulties in unmanaged C++, but there's no issue
about it in .NET.

There are plenty of system libraries which do it, and quite rightly in
my view. If you try to create a reading FileStream on a file which
doesn't exist, I think it's perfectly reasonable to throw an exception.

 

[Nick Hounsome]

You could simply try making the constructor private and using a static
method to call it (and do the "dirty" work which could fail):

<snip>

Why make the ctor private?
If you leave it public you can have it either way.

 

[Nick Hounsome]

And it's bad practice to do any substantial work in your constructor. It's
nasty to have constructors throw exceptions too. I would recommend just
*constructing* in your constructor and putting the meaty work into a
separate method.

It is not bad practice!

IMHO when designing anything invariants are your greatest aid to
understanding and bug free code and constructors that don't do all the work
drastically reduce the number of invariants in your class and typically
increase the number of states from 2 (initialized,disposed) to 3
(+uninitialized) [Unfortunately you cannot reduce it to just 1 state as you
can with C++]

Furthermore do you propose that the init method should throw an exception?
In which case what have you gained?