 <p>It depends.</p> <p>If the validation is simple, and can be checked using only information contained in the class, then most of the time it's worth while to add the state checks to the class.</p> <p>There are sometimes, however, where it's not really possible or desirable to do so.</p> <p>A great example is a compiler. Checking the state of abstract syntax trees (ASTs) to make sure a program is valid is usually not done by either property setters or constructors. Instead, the validation is usually done by a tree visitor, or a series of mutually recursive methods in some sort of "semantic analysis class". In either case, however, properties are validated long after their values are set.</p> <p>Also, with objects used to old UI state it's usually a bad idea (from a usability perspective) to throw exceptions when invalid values are set. This is particularly true for apps that use WPF data binding. In that case you want to display some sort of modeless feedback to the customer rather than throwing an exception.</p>