Throwing Exceptions from Property

[Sek]

Gurus,

I am wondering whether it is right to throw an exception from a
Property of an object.

To get into it further, is it okay to throw exception during 'get'
operation?

I was searching for MS articles on throwing exceptions. But, in vain.

I am curious to know more on this.

-Sek

 

[Guest]

Not good. Because they wonder to get exception from the common
obj.Name = "name";

If u need to throw exception use method for this, it's more expected

Gurus,
I am wondering whether it is right to throw an exception from a
Property of an object.
To get into it further, is it okay to throw exception during 'get'
operation?

I was searching for MS articles on throwing exceptions. But, in vain.

I am curious to know more on this.

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Sek]

Thanks for the info.

But, how about throwing exception during a 'Set' operation. I don't see
any other way of converying the failure of 'Set' operation.

 

[Leon Lambert]

Why not? Properties are just syntactic candy for a method call. They are
actually method calls in the IL code. They are typically used to do pre
or post processing of the value to validate it. So it certainly could
throw an exception if the value is invalid.

Leon Lambert

 

[Sek]

Makes sense.

Thanks a lot for the explanation.

 

[Jon Skeet [C# MVP]]

Not good. Because they wonder to get exception from the common
obj.Name = "name";

If u need to throw exception use method for this, it's more expected

On the contrary - one of the reasons for using a property rather than a
straight public field is to enable validation of the given value.

For instance, look at StringBuilder.Length, which is documented to
throw an exception if you give it an inappropriate value.

Jon

 

[Guest]

design issue, isn't it? We can call method from the set property

On the contrary - one of the reasons for using a property rather than a
straight public field is to enable validation of the given value.

For instance, look at StringBuilder.Length, which is documented to
throw an exception if you give it an inappropriate value.

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Jon Skeet [C# MVP]]

design issue, isn't it?

Absolutely - but I disagree with your design viewpoint that properties
shouldn't throw exceptions.

We can call method from the set property

But if that throws an exception, we're back to the point of contention
- whether it's okay for properties to throw exceptions or not.

Jon

 

[Ignacio Machin \( .NET/ C# MVP \)]

HI,

Not good. Because they wonder to get exception from the common
obj.Name = "name";

It's not only good but expected, how otherwise you will react to a wrong
value being assigned to a property?

If u need to throw exception use method for this, it's more expected

An exception is expected wherever an error occur. it does not matter where.

 

[Lucian Wischik]

I am wondering whether it is right to throw an exception from a
Property of an object.

MyClass x = null;
string s = x.Name;

int[] x = new int[10];
int i = x[15];

If exceptions are reasonable even for value-getting, I think they're
fine also for property-getting.

 

[Brian Gideon]

Sek,

The Framework Design Guidelines book recommends avoiding exceptions in
property getters. If a getter needs to throw an exception then it
should probably be refactored into a method. The rule does not apply
to setters or indexers though.

Brian

 

[Nick Hounsome]

I am wondering whether it is right to throw an exception from a
Property of an object.

MyClass x = null;
string s = x.Name;

int[] x = new int[10];
int i = x[15];

If exceptions are reasonable even for value-getting, I think they're
fine also for property-getting.

As I explained elsewhere, there is a difference between exceptions caused by
the caller's carelessness (OK) and exception caused by the object failing to
fulfill its description as a possesor of a certain property (Not OK).

MyClass x says that it has a Name property. If the getter throws then it
lied and there is no way that the caller could avoid it.

int[] x never said it had 16 elements. If you treat it like its has then you
will get an exception. The caller can always check with if(x.Length >=16).

 

[jeremiah johnson]

The general consensus here is that they're OK, and I agree with that.

Throw an exception whenever it makes sense to do so. That's a vague
definition, but generally I throw exceptions whenever I need to validate
anything.

If I need to validate input, I always thrown an exception. When I need
to validate output, I always throw an exception.

I might not be doing things correctly, but it seems to work okay for me.

jeremiah

 

[Bill Butler]

The general consensus here is that they're OK, and I agree with that.

Throw an exception whenever it makes sense to do so. That's a vague definition, but generally I
throw exceptions whenever I need to validate anything.

If I need to validate input, I always thrown an exception. When I need to validate output, I
always throw an exception.

I might not be doing things correctly, but it seems to work okay for me.

While I do agree that you should throw an exception when it makes sense to do so, I also believe
that if you need to throw exceptions in your properties, you should at least consider refactoring
your design.

Let me Splain.

A classic case of needing validation is Dates and times.
Is the month between 1 and 12 (or is it 0 and 11)
Is the day between...
You get the idea.

Now look at the DateTime struct.
None of its properties throw an exception.
All of the validation (exception throwing) is in the constructor.

This goal is not always achievable, but in general, you should think about it.

my 2 cents
Bill

 

[Jon Skeet [C# MVP]]

Let me Splain.

A classic case of needing validation is Dates and times.
Is the month between 1 and 12 (or is it 0 and 11)
Is the day between...
You get the idea.

Now look at the DateTime struct.
None of its properties throw an exception.
All of the validation (exception throwing) is in the constructor.

This goal is not always achievable, but in general, you should think about it.

That's just because none of its properties have setters - DateTime is
immutable. Immutability is great where appropriate, but it's far from
always appropriate.

There are plenty of other places in the framework which *do* validate
in properties and throw exceptions.

 

[Bill Butler]

That's just because none of its properties have setters - DateTime is
immutable. Immutability is great where appropriate, but it's far from
always appropriate.

There are plenty of other places in the framework which *do* validate
in properties and throw exceptions.

<grin>
Hi Jon,
I was well aware of the immutably factor when I posted. I went back and forth with myself about
using that particular example, but decided in favor of it due to all of the issues involved if you
allowed DateTime objects to have their properties set individually.
You are absolutely correct.I was just attempting to point out that sometimes it makes more sense to
Put your validation code in the constructor, or in a method.
If DateTime was an class and not a struct, you could still make a good argument for making it behave
in a similar fashion to the way it does now.
If you set the Day to 31....is that valid??? We don't know until we know what month.
What about 29 FEB ? IS it a leap year

Another thing you see frequently in the framework is properties that *Could* be integer values with
range validation. Instead they are refactored to take an object/struct that validated the range in
it's constructor.

I really don't disagree with you at all.
I am simply saying that you should at least *consider* refactoring if you run into a similar
situation.
I was just arguing in favor of exceptions in properties in another thread a couple of days ago ;^)

I guess I just like looking at both sides of the issue.

Bill