Generally speaking, I'd disagree with Jon B regarding when to throw the exception - if it is thrown on the call to set() it will capture the context of when the invalid value was set. On the other hand, if you just set it to some dummy value and throw the exception elsewhere, then depending on the approach you take, the client will either see the dummy value with no indication that this was not the value actually set, or they will receive an exception that doesn't give them any idea of who is responsible for the invalid state or how to rectify it.
Now in some situations this technique might make sense - if for some unavoidable reason the property is extremely volatile, and you've decided that it's fine for illegal properties to be set transiently, but (based on some external synchronisation) the client is not allowed to retrieve the property until it is known to be a legal, stable value. This isn't great either, but I'm sure it's possible to be in a situation where you can't help this situation.
And since you asked about languages other than .NET, in Java I would use an IllegalArgumentException in the general case - perhaps a good old NullPointerException if the argument is null.