You want to delve a bit in the remarkable work of Paul Stovell concerning data validation. He summed up his ideas at one time in this article. I happen to share his point of view on the matter, which I implemented in my own libraries.
Here are, in Paul’s words, the cons to throwing exceptions in the setters (based on a sample where a Name property should not be empty) :
- There may be times where you actually need to have an empty name. For example, as the default value for a “Create an account” form.
- If you’re relying on this to validate any data before saving, you’ll miss the cases where the data is already invalid. By that, I mean, if you load an account from the database with an empty name and don’t change it, you might not ever know it was invalid.
- If you aren’t using data binding, you have to write a lot of code with
try/catchblocks to show these errors to the user. Trying to show errors on the form as the user is filling it out becomes very difficult.- I don’t like throwing exceptions for non-exceptional things. A user setting the name of an account to “Supercalafragilisticexpialadocious” isn’t an exception, it’s an error. This is, of course, a personal thing.
- It makes it very difficult to get a list of all the rules that have been broken. For example, on some websites, you’ll see validation messages such as “Name must be entered. Address must be entered. Email must be entered”. To display that, you’re going to need a lot of
try/catchblocks.
And here are basic rules for an alternative solution :
- There is nothing wrong with having an invalid business object, so long as you don’t try to persist it.
- Any and all broken rules should be retrievable from the business object, so that data binding, as well as your own code, can see if there are errors and handle them appropriately.