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: David Abrahams (dave_at_[hidden])
Date: 2008-12-23 02:16:36

on Sun Dec 21 2008, Mika Heiskanen <mika.heiskanen-AT-fmi.fi> wrote:

> David Abrahams wrote:
>> on Sat Dec 20 2008, Mika Heiskanen <mika.heiskanen-AT-fmi.fi> wrote:
>>
>>> David Abrahams wrote:
>>>
>>>> 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?

No.  In general libraries, invalid user input should be reported via a
different mechanism, because there's no reason to believe that the
condition should be handled far from the site where validation is
requested.  If you decide that throwing is an appropriate response for
your application, you can do that in a layer outside the validation.

> 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.

Stop the program immediately.  If appropriate, execute emergency
shutdown measures.  Do not unwind stack, do not pass "Go," do not
collect $200. ;-)

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com