Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've always been of the mindset that properties (ie, their set/get operations) should be fast/immediate and failure-free. You should never have to try/catch around getting or setting a property.

But I'm looking at some ways to apply role-based security on the properties of some objects. For instance an Employee.Salary property. Some of the solutions I've run across that others have tried (one in particular is the AOP example here) involve throwing an exception if the accessor doesn't have the right permissions - but this goes against a personal rule that I've had for a long time now.

So I ask: am I wrong? Have things changed? Has it been accepted that properties should be able to throw exceptions?

share|improve this question
1  
This same question on StackOverflow got more attention and so better answers. –  romkyns Aug 19 '13 at 13:24

6 Answers 6

up vote 10 down vote accepted

when you set the value of a property, throwing an exception on an invalid value is fine

getting the value of a property should (almost) never throw an exception

for role-based access, use different/dumber interfaces or facades; don't let people see things they can't have!

share|improve this answer

Although a lot will depend on the context I'd generally avoid putting any sort of breakable logic (including exceptions) into properties. Just as one example, there's a lot of things which you (or some library that you're using) could do which use reflection to iterate over properties resulting in errors you didn't anticipate at design-time.

I say generally though as there may be some times when you absolutely, definitely, want to block something without worrying too much about the consequences. Security I guess would be the classic case there.

share|improve this answer

I consider it to mostly be bad form but even Microsoft recommends using exceptions sometimes. A good example is the abstract property Stream.Length. As guidelines go I would be more concerned with avoiding side effects on getters and limiting side effects on setters.

share|improve this answer

The point of a property is the Uniform Access Principle, i.e. that a value should be accessible through the same interface whether implemented by storage or computation. If your property is throwing an exception that represents an error condition beyond the programmer's control, the kind that is supposed to be caught and handled, you are forcing your client to know that the value is obtained via computation.

On the other hand, I don't see any problem with using asserts or assertion-like exceptions that are meant to signal incorrect use of the API to the programmer rather than being caught and handled. In these cases the correct answer from the API user's perspective isn't to handle the exception (thus implicitly caring about whether the value is obtained via computation or storage). It's to fix his/her code so the object doesn't end up in an invalid state or make you fix your code so the assertion doesn't fire.

share|improve this answer
    
I don’t see how “you are forcing your client to know that the value is obtained via computation” follows. Certainly access to storage can throw an exception too. In fact, how would you even define the difference between the two? –  Timwi Nov 4 '10 at 5:24
    
I believe the distinction being made is that simply retrieving a value from a field (storage) and doing something innocuous with it, such as placing it in a variable of an appropriate type (i.e. without casting), can't throw an exception. In that case an exception could only occur if you subsequently did something with the value. If an exception is being thrown in a property getter, then in that case simply the act of retrieving the value and placing it in a variable could cause an exception. –  Dr. Wily's Apprentice Nov 4 '10 at 18:33

I know your question is specific to .NET, but since C# shares some history with Java, I thought you might be interested. I am not in any way implying that because something is done in Java, it should be done in C#. I know the two are very different, especially in how C# has much-improved language-level support for properties. I am just giving some context and perspective.

From the JavaBeans specification:

Constrained properties Sometimes when a property change occurs some other bean may wish to validate the change and reject it if it is inappropriate. We refer to properties that undergo this kind of checking as constrained properties. In Java Beans, constrained property setter methods are required to support the PropertyVetoException. This documents to the users of the constrained property that attempted updates may be vetoed. So a simple constrained property might look like:

PropertyType getFoo();
void setFoo(PropertyType value) throws PropertyVetoException;

Take all this with a grain of salt, please. The JavaBeans specification is old, and C# Properties are (IMO) a huge improvement over the "naming convention" based properties that Java has. I'm just trying to give a little context, is all!

share|improve this answer
    
It's a good point, but the distinction between a setter method and a c# property setter is significant enough to be a different case for me. Likewise, Java's checked exceptions force the calling code to be aware that an exception can be thrown, so there's less chance that this will catch anyone by surprise. –  Steve Evers Nov 5 '10 at 16:39

AFAIK, this guidance primarily comes from the thought process that properties may end up used at design time. (E.g. the Text property on a TextBox) If the property tosses an exception when a designer's trying to access it, VS isn't going to have a good day. You will get a bunch of errors just trying to use the designer and for the UI designers, they won't render. It also applies to debug time as well, although what you'll see in an exception scenario is just "xxx Exception" and it won't clobber VS IIRC.

For POCOs, it won't really do any harm, but I still shy away from doing it myself. I figure people will want to access properties more frequently, so they should normally be low cost. Properties shouldn't do the work of methods, they should just get/set some info and be done with it as a general rule.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.