Throwing Argument Exceptions in Property Setters

[Mike Hofer]

Okay, silly question. Nitpicky, sure, but it bugs me.

Range-checking parameters in a property setter. For example, an Enum
property with one of two possible values:

Public Property MyEnumProperty() As MyEnumType
Get
Return m_myEnumProperty
End Get
Set(ByVal Value As MyEnumType)
If Value <MyEnumType.Value1 And Value <MyEnumType.Value2
Then
Throw New ArgumentOutOfRangeException("value")
End If
End Set
End Property

(Tacky code for illustrative purposes only!)

My question is this: When you guys are throwing an ArgumentException
in a property setter, do you specify "value" as the argument to the
exception, or do you use the name of the property?

It would *seem* that the correct answer is "value", the name of the
parameter. However, that's hardly helpful. You have to examine the
stack trace to determine which property threw the exception.

I am sorely tempted to use the property name to simplify defect
resolution. But I'm not sure that's a good idea.

On the other hand, I've considered a separate exception class that
indicates "Invalid property value" or something like that without
muddying the property name/parameter name waters.

So any advice you folks can provide would be appreciated.

Thanks in advance!

[Kevin Spencer]

I use the property name.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@o5g2000hsb.googlegro ups.com...

Okay, silly question. Nitpicky, sure, but it bugs me.

Range-checking parameters in a property setter. For example, an Enum
property with one of two possible values:

Public Property MyEnumProperty() As MyEnumType
Get
Return m_myEnumProperty
End Get
Set(ByVal Value As MyEnumType)
If Value <MyEnumType.Value1 And Value <MyEnumType.Value2
Then
Throw New ArgumentOutOfRangeException("value")
End If
End Set
End Property

(Tacky code for illustrative purposes only!)

My question is this: When you guys are throwing an ArgumentException
in a property setter, do you specify "value" as the argument to the
exception, or do you use the name of the property?

It would *seem* that the correct answer is "value", the name of the
parameter. However, that's hardly helpful. You have to examine the
stack trace to determine which property threw the exception.

I am sorely tempted to use the property name to simplify defect
resolution. But I'm not sure that's a good idea.

On the other hand, I've considered a separate exception class that
indicates "Invalid property value" or something like that without
muddying the property name/parameter name waters.

So any advice you folks can provide would be appreciated.

Thanks in advance!

[Henning Krause [MVP - Exchange]]

Hello,

If I recall the Framework Design Guidelines correctly, you should not throw
an argument in a property setter. Rather throw an exception when the
property is used in member method.

Best regards,
Henning Krause

"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@o5g2000hsb.googlegro ups.com...

Okay, silly question. Nitpicky, sure, but it bugs me.

Range-checking parameters in a property setter. For example, an Enum
property with one of two possible values:

Public Property MyEnumProperty() As MyEnumType
Get
Return m_myEnumProperty
End Get
Set(ByVal Value As MyEnumType)
If Value <MyEnumType.Value1 And Value <MyEnumType.Value2
Then
Throw New ArgumentOutOfRangeException("value")
End If
End Set
End Property

(Tacky code for illustrative purposes only!)

My question is this: When you guys are throwing an ArgumentException
in a property setter, do you specify "value" as the argument to the
exception, or do you use the name of the property?

It would *seem* that the correct answer is "value", the name of the
parameter. However, that's hardly helpful. You have to examine the
stack trace to determine which property threw the exception.

I am sorely tempted to use the property name to simplify defect
resolution. But I'm not sure that's a good idea.

On the other hand, I've considered a separate exception class that
indicates "Invalid property value" or something like that without
muddying the property name/parameter name waters.

So any advice you folks can provide would be appreciated.

Thanks in advance!

[Jon Skeet [C# MVP]]

Henning Krause [MVP - Exchange] <ne***************@this.infinitec.de>
wrote:

If I recall the Framework Design Guidelines correctly, you should not throw
an argument in a property setter. Rather throw an exception when the
property is used in member method.

No way - part of what properties are there for is to allow validation
to be encapsulated.

See http://msdn2.microsoft.com/en-us/lib...06(VS.80).aspx

<quote>
It is valid and acceptable to throw exceptions from a property setter.
</quote>

However, the same page *does* say that it's not a good idea to throw
exceptions from a getter. Might that be what you're thinking of?

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

[Henning Krause [MVP - Exchange]]

Hello Jon,

>
However, the same page *does* say that it's not a good idea to throw
exceptions from a getter. Might that be what you're thinking of?

Yes, that's right. Just looked it up in the book.

Best regards,
Henning Krause

[Henning Krause [MVP - Exchange]]

In fact, I confused it with the statement

"Do allow properties to be set in any order even if this results in a
temporary invalid state of the object."

In this situation, exceptions should deferred to the point where they are
used together.

Best regards,
Henning Krause

"Henning Krause [MVP - Exchange]" <ne***************@this.infinitec.de>
wrote in message news:e2**************@TK2MSFTNGP02.phx.gbl...

Hello Jon,

>>
However, the same page *does* say that it's not a good idea to throw
exceptions from a getter. Might that be what you're thinking of?

Yes, that's right. Just looked it up in the book.

Best regards,
Henning Krause

[Jon Skeet [C# MVP]]

Henning Krause [MVP - Exchange] <ne***************@this.infinitec.de>
wrote:

In fact, I confused it with the statement

"Do allow properties to be set in any order even if this results in a
temporary invalid state of the object."

In this situation, exceptions should deferred to the point where they are
used together.

Personally, I try to avoid using properties for that kind of thing -
I'd rather have a setter method which took both values and validated
them against each other. Either that or have a separate
"initialisation/validation" step which means "I've finished setting
properties now - validate them and don't let me change them again".

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