|
Boost : |
From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-12 17:33:49
At 1:48 PM +0000 4/12/01, williamkempf_at_[hidden] wrote:
>--- In boost_at_y..., Jesse Jones <jesjones_at_h...> wrote:
>> >Again, std::vector::at() exists for precisely this reason, and C++
>> >programmers use it in precisely the same manner as IndexError is
>> >used. I don't agree that we have a completely different culture in
>> >this case. There are many C++ programmers that want, even need, to
>> >insure their programs never crash... that they can catch errors,
>> >possibly handle them, and continue running.
>>
>> Throwing for DbC violations is not going to help you reach this
>goal.
>
>First, we're not necessarily talking DbC here. I wouldn't consider
>the semantics of at() to be a DbC model.
>
You may not be talking DbC, but I am. :-)
> > Once this happens you know you've found a bug but there's no way to
>> know if you've found it early enough to avoid corrupting the state
>of
>> the system. I think most software of this ilk would rather shutdown
>> than chance continuing with a possibly corrupt app.
>
>There's a huge difference between "shutdown" and "halt". In many
>cases it's possible to handle errors with out needing to shutdown at
>all, but even in the worst cases many programs will *NEED* to
>shutdown in some proper manner (save data first even if it may be
>partially corrupt, spawn a new instance to insure other incoming
>requests are handled, etc.) and a program halt, whether it's from an
>assert or an access violation, etc., is simply disastrous.
Sure all of that is desirable. All I'm saying is that it's preferable
for critical software to crash rather than limp along with possibly
corrupt state. Things like an X-ray machine or an auto-pilot fit this
bill I think.
-- Jesse
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk