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

 

[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

 

[Jon Skeet [C# MVP]]

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/library/ms229006(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?

 

[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

 

[Jon Skeet [C# MVP]]

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