From: williamkempf_at_[hidden]
Date: 2001-04-11 17:43:12
--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
>
> ----- Original Message -----
> From: <williamkempf_at_h...>
>
> > C++ platforms (MSVC) that throw exceptions when an assertion
fires?
> > Some alternative library assertion packages may do this, but none
> > that come with MSVC throw exceptions. I was speaking of other
> > languages here.
>
> What does this program do with msvc?
>
> include <cassert>
> #include <iostream>
>
> int main() {
> try {
> assert(0);
> }
> catch(...) {
> std::cout << "hi there" << std::endl;
> }
> return 0;
> }
>
> Try compiling it as follows:
> cl /MLd /GX /EHa foo.cpp
It halts the program. Even if you Ignore the assertion the catch
block is never entered. Like I said, none of the assertion libraries
that come with MSVC throw exceptions.
> > > Other languages have different exception models, so its hard to
> > make a case
> > > about C++ exception use policy on that basis. For example, I
would
> > have no
> > > serious objections to throwing an exception from assert() if the
> > exception
> > > could carry a snapshot of the program state (before unwinding)
with
> > it. This
> > > sort of thing is possible with LISP systems.
> >
> > It's possible with C++ as well. There's nothing in the standard
> > preventing this that I can see. Granted, it's not required
either,
> > which may be what you're getting at, but it's also not required
for
> > an assertion to be able to give you this type of information
either.
>
> That's right. Of course there are differences between theory and
practice.
> In practice, C++ exceptions don't do this (and there's a good
reason - it
> would be way too expensive), but sometimes assertions do.
>
> Another note: other languages have different error models. For
example,
> interpreted languages like LISP, Java, and pure Python should never
crash,
> no matter what bugs a user puts in his program. In principle, it
should be
> possible to avoid anything like unpredictable behavior (although I
think the
> latter two fail to acheive this goal due to poor specification).
The price
> paid for this kind of security is, of course, speed. No real C++
> implementation is willing to accept this performance hit, so there
are
> plenty of ways to crash a program. I think this leads to a different
> programming model. For example, in Python, iteration through a
sequence is
> terminated with an IndexError exception. It isn't incorrect to
index off the
> end of a Python sequence - it happens all the time. We wouldn't do
that in
> C++, but not just because of the performance problem: we have a
different
> culture, a different way of looking at program correctness.
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.
> > > I don't think it would be fair to say that I violate my own
rules:
> > I'm
> > > saying it's a choice you have to think about. There are
tradeoffs.
> > Not every
> > > programming decision can be made by prescription.
> >
> > I didn't single out any one person when I said "they" break their
own
> > rules. By your own admission here you don't have rules but
instead
> > have what I'd consider loose guidelines.
>
> They're not really as loose as they may seem. I pretty much always
assert
> invariants and preconditions. I'm just unwilling to pass judgement
against
> someone who thinks they stand a better chance of recovery in a
> mission-critical application by turning all precondition violations
into
> exceptions for the shipping product. IMO, a precondition violation
almost
> always means some program invariant is broken, so recovery is
unlikely.
> These people are gambling... who am I to tell them how to place
their bets?
It's not always a gamble, as illustrated by the std::vector::at()
scenario above.
> > Every time this subject has
> > come up, however, the arguments always state hard and fast
rules. To
> > further complicate matters, even if you take these rules as loose
> > guidelines instead, every person seems to have their own set.
>
> Maybe so.
>
> > I've
> > never seen this topic come up where any kind of concensus is
> > reached. I'm truly at a loss to understand when and when not to
use
> > exceptions.
>
> I guess you'll just need to sort through the arguments and see
which ones
> ring true for you, then. Wish I could offer something more/better...
That doesn't help Boost in general. If everyone does this we
constantly have this argument and have various libraries handle
things differently with a large number of people upset with the
decision regardless of what it was.
Bill Kempf