By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,806 Members | 1,506 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,806 IT Pros & Developers. It's quick & easy.

Throwing Argument Exceptions in Property Setters

P: n/a
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!

Apr 23 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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!

Apr 23 '07 #2

P: n/a
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!
Apr 23 '07 #3

P: n/a
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
Apr 23 '07 #4

P: n/a
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
Apr 24 '07 #5

P: n/a
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
Apr 24 '07 #6

P: n/a
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
Apr 24 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.