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
"Bruce Wood" <br*******@canada.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com...

No there is not.

You have to throw an exception.

[Flo 'Irian' Schaetz]

"tshad" <ts**********@ftsolutions.com> wrote

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]]

Kent Boogaart <ke****@internode.on.net> wrote:

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Nick Hounsome]

"Flo 'Irian' Schaetz" <ir***@arcor.de> wrote in message
news:44***********************@newsread4.arcor-online.net...

"tshad" <ts**********@ftsolutions.com> wrote

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):

<snip>

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

[Nick Hounsome]

"Kent Boogaart" <ke****@internode.on.net> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...

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?