2

I always hear people who say setters and getters should be fast and not throw exceptions.

Now, if it is true, how should I handle an invalid value passed to a setter, if not throwing an exception?

Community
  • 1
  • 1
Michael Haddad
  • 4,085
  • 7
  • 42
  • 82
  • 3
    "should be fast and not throw exceptions" never heard of it. I always use exception, if I want to validate the setter. –  Jul 07 '16 at 08:07
  • I think there is no crime to throwing exception in setter. – Anton Semenov Jul 07 '16 at 08:08
  • I'm voting to close this question as off-topic because it seems to be based on a false premise, with no supporting links/docs. – Damien_The_Unbeliever Jul 07 '16 at 08:09
  • 1
    The whole point of a property is that it does *more* than simply setting a value (well, and adds a better opportunity for encapsulation). Of course it's fine to throw an exception - but yes, properties should be fast, especially for reading. – Luaan Jul 07 '16 at 08:09
  • If you aren't going to check/validate the value, why not just use a field? – CompanyDroneFromSector7G Jul 07 '16 at 08:10
  • I've heard that properties shouldn't hide expensive actions, but general validation or exceptions are fine. Alternatively, a completely different pattern could be used via methods with a return type of validation issues (if any). IMO validation failures are not exceptional so shouldn't be exceptions. – Adam Houldsworth Jul 07 '16 at 08:10
  • You are correct what you've heard. Microsoft best practises stipulate not to throw exceptions in Setters. Can't seem to find the documentation on this at the moment. – Chris Walsh Jul 07 '16 at 08:11
  • Edited my question. Please review it. – Michael Haddad Jul 07 '16 at 08:13
  • From your own reference "For setters they indicate that exceptions are an appropriate and acceptable error handling strategy." – Justin Harvey Jul 07 '16 at 08:14

2 Answers2

8

As per MSDN

AVOID throwing exceptions from property getters.

Property getters should be simple operations and should not have any preconditions. If a getter can throw an exception, it should probably be redesigned to be a method. Notice that this rule does not apply to indexers, where we do expect exceptions as a result of validating the arguments.

Having said that, to me, it is absolutely fine to throw exception from setter and normally getters should never throw exception.

Consider a property as attribute or characteristic of the object. So when ever you are taking value of that attribute, you should get is without any exception. You would also want that, no one should be able to set invalid value to it, so it is fine to throw exception while setting the value.

Also as a good practice, do preserve the previous value if a property setter throws an exception. so that the integrity of the object is maintained. MSDN

You can find some good discussion here - https://softwareengineering.stackexchange.com/questions/16646/is-throwing-an-exception-from-a-property-bad-form

Community
  • 1
  • 1
Yogi
  • 9,174
  • 2
  • 46
  • 61
1

Actually, I think it is true mainly for constructors not to throw exceptions.

For getters/setters the problem is that bindings (like WPF) might cause some problems throwing exceptions in getters/setters.

But normally there is not that much that can cause an exception, except problems during development (pre-used objects being null?).

Validation problems should not be exceptions. Exceptions are cases that should be really unusual circumstances (like an expected file that is not existing, memory shortage). Input validation and checking if a user inputted file exist should not be exceptions for example.

Michel Keijzers
  • 15,025
  • 28
  • 93
  • 119