Re: [boost] [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today

Subject: Re: [boost] [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-21 07:27:41

> 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