Throwing Argument Exceptions in Property Setters

  • Thread starter Thread starter Mike Hofer
  • Start date Start date
M

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!
 
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
 
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
 
Henning Krause said:
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.
Click to expand...

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?
 
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?
Click to expand...

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

Best regards,
Henning Krause
 
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 said:
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.
Click to expand...

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