From: Mika Heiskanen
Exceptions should almost never be used in response to broken invariants. Pardon my ignorance, but how come? The constraints I have to validate usually concern broken user input
That's not a broken invariant. A broken invariant means your program is broken.
via the command line or a query string. How should I deal with them if not with exceptions? Or to be more precise, why should I not use constrained types for validating user input if it saves me a lot of if-statements in the long run?
I would never argue that you shouldn't do that.
So you see why I would prefer the constrained value class being reviewed to throw?
Also, pardon my ignorance again, but would you care to explain how an expert would handle broken invariants in broken programs if not via exceptions? I was not aware there is a better solution.
There seems to be confusion between broken invariant and assignment of invalid value. The latter is handled by the error policy and it is its duty to prevent breaking the invariant. One of the ways to prevent it is throwing an exception, other ones are adjusting the value to be valid or ignoring the assignment. If the invariant gets broken, then it means there's something wrong either with your error policy, the constraint policy or the value type, because they do not fulfil the requirements of constrained class. So, as David has pointed out, broken invariant means that the programmer has done something wrong. Best regards, Robert