throwing exception from constructor

[Sek]

Is it appropriate to throw exception from a constructor?

Thats the only way i could think of to denote the failure of
constructor, wherein i am invoking couple of other classes to
initialise the object.

TIA
Sek

[simida]

As far as i know, It's not a appropriate way to throw exception from a
constructor.
If you can make sure that when exception occured, you should dispose
all resoures, such as, File handler, memory, etc.

Sek 写�：

Is it appropriate to throw exception from a constructor?

Thats the only way i could think of to denote the failure of
constructor, wherein i am invoking couple of other classes to
initialise the object.

TIA
Sek

[Jon Skeet [C# MVP]]

Sek wrote:

Is it appropriate to throw exception from a constructor?

Thats the only way i could think of to denote the failure of
constructor, wherein i am invoking couple of other classes to
initialise the object.

Yup, that's fine. Several framework types do it. For examples, see
Guid(string), the FileStream constructors, and String(char[], int,
int).

Jon

[Jon Skeet [C# MVP]]

simida wrote:

As far as i know, It's not a appropriate way to throw exception from a
constructor.

It's widely done, and there's no reason not to do it in .NET. In
unmanaged C++ there are reasons why it's a bad idea, but they don't
apply to .NET.

If you can make sure that when exception occured, you should dispose
all resoures, such as, File handler, memory, etc.

File handles etc, yes - but memory will automatically be cleaned up by
the garbage collector.

Jon

[chanmm]

Contructor supposed to handle simple tasks like initialization. If up to the
stage you need to throw exception from contructor I think I would suggest
you to review the code.

chanmm

"Sek" <se****@gmail.c omwrote in message
news:11******** *************@s 13g2000cwa.goog legroups.com...

Is it appropriate to throw exception from a constructor?

Thats the only way i could think of to denote the failure of
constructor, wherein i am invoking couple of other classes to
initialise the object.

TIA
Sek

[Jon Skeet [C# MVP]]

chanmm wrote:

Contructor supposed to handle simple tasks like initialization. If up to the
stage you need to throw exception from contructor I think I would suggest
you to review the code.

Initialization can quite often suggest throwing exceptions,
particularly based on the parameters. What would you suggest FileStream
should do if it's been asked to open a file for reading and the file
doesn't exist?

Jon

[Leon Lambert]

As many have stated it is ok to throw an exception in the constructor.
Having said that i would recommend against it. Over the years i have
found it helped me a lot better to just have constructors put the object
into a safe state. I do work that might throw exceptions in a different
method like Setup. I forget all the pains i had in the past that
eventually brought my to doing things this way because I just do it as a
matter of course now.

Leon Lambert

Sek wrote:

Is it appropriate to throw exception from a constructor?

Thats the only way i could think of to denote the failure of
constructor, wherein i am invoking couple of other classes to
initialise the object.

TIA
Sek

[Brian C. Barnes]

I agree with what Lambert wrote. I have always tried to insure that
constructors simply put things into an "initialize d" state. If you have to do
something more involved, and especially anything that might throw an
exception or have other failures, I always put them into a "Create" or "Open"
type of function. Yes, this can lead to other errors (i.e. forgetting to call
the appropriate Create function), but I just like it better because of all
the "magic" constructors that happen behind your back (copy constructors,
etc.).

"Leon Lambert" wrote:

As many have stated it is ok to throw an exception in the constructor.
Having said that i would recommend against it. Over the years i have
found it helped me a lot better to just have constructors put the object
into a safe state. I do work that might throw exceptions in a different
method like Setup. I forget all the pains i had in the past that
eventually brought my to doing things this way because I just do it as a
matter of course now.

Leon Lambert

Sek wrote:

Is it appropriate to throw exception from a constructor?

Thats the only way i could think of to denote the failure of
constructor, wherein i am invoking couple of other classes to
initialise the object.

TIA
Sek

[Jon Skeet [C# MVP]]

Leon Lambert wrote:

As many have stated it is ok to throw an exception in the constructor.
Having said that i would recommend against it. Over the years i have
found it helped me a lot better to just have constructors put the object
into a safe state. I do work that might throw exceptions in a different
method like Setup. I forget all the pains i had in the past that
eventually brought my to doing things this way because I just do it as a
matter of course now.

So how would you implement FileStream? If you don't do anything in the
constructor, it's just saving the exception for later on - where's the
advantage of that? Yes, the object would be in a "safe" state - but
it's useless until it's opened the file, and that's the point at which
you should throw an exception if the file can't be found, IMO.

Jon

[Jon Skeet [C# MVP]]

Brian C. Barnes wrote:

I agree with what Lambert wrote. I have always tried to insure that
constructors simply put things into an "initialize d" state. If you have to do
something more involved, and especially anything that might throw an
exception or have other failures, I always put them into a "Create" or "Open"
type of function. Yes, this can lead to other errors (i.e. forgetting to call
the appropriate Create function), but I just like it better because of all
the "magic" constructors that happen behind your back (copy constructors,
etc.).

C# doesn't *have* "magic" constructors though. I really don't see the
advantage of forcing the client to make two calls when one would do.
The *only* point I could see is that if you're implementing
IDisposable, you need to make sure that your constructor cleans up
after itself if it throws an exception after acquiring a resource. If
you do that in the Create method, you can assume that the client will
call Dispose appropriately.

However, using a Create/Initialize/etc method means that your object
isn't really *usable* when the constructor has returned, which is the
state I like to be in.

It's quite possible that throwing exceptions from constructors is a bad
idea in other environments, but I think it's fine in C#.

Jon