|
Boost : |
Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Peter Simons (simons_at_[hidden])
Date: 2008-12-21 06:10:14
Hi Mika,
> 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.
I guess David means to distinguish between run-time errors and invariants
failures. Run-time errors are expected conditions. An attempt to open a file
may fail. An attempt to connect to a remote host over the network may fail.
Your program is supposed to anticipate those conditions. Run-time errors may
or may not be signalled by exceptions, depending on whether stack unwinding
is desirable or not.
Invariant failures, however, are unexpected conditions. Invariants are not
supposed to fail. If they do, it's a sign of incorrect program logic or
faulty assumptions. Your program will generally not be able to recover from
such an error, hence invariant checking functions like assert() typically
abort the process on failure (and generate debugging information, such as a
core dump).
I hope this helps,
Peter
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk