|
Boost : |
From: jhopkin_at_[hidden]
Date: 2003-07-18 06:00:24
I agree that logic errors should be caught by assertions.
The problem with throwing from logic errors is that when a logic error
occurs, all bets are off.
For example, if memory allocation fails, stack unwinding is the right thing
to do, because it's clear what the code was intended to do and what part of
that has failed. Allocation failed => pretend object never existed and
handle it higher up the call stack.
If the program fails because the client code does something unexpected, how
can we know what was intended? In the lock example, should the program
ideally then rewind to before the initial lock happened and say 'please try
again'?. In general, that's impractical, even if it could be ascertained
what action should be taken.
The lock library should assert on logic errors (IMO), but of course it's
trivial to wrap it if in a given application user input can cause 'logic
errors'. That's a user interface issue, so the UI should check the input
before passing onto the underlying library code:
void UI::lock()
{
if (m_lock.is_locked()) { throw lock_error; }
else { m_lock.lock();
}
}
-Virus scanned and cleared ok
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk