Boost logo

Boost :

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
> > 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
> > have no
> > > serious objections to throwing an exception from assert() if the
> > exception
> > > could carry a snapshot of the program state (before unwinding)
> > 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
> > which may be what you're getting at, but it's also not required
> > an assertion to be able to give you this type of information
> That's right. Of course there are differences between theory and
> 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
> interpreted languages like LISP, Java, and pure Python should never
> 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
> 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
> 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
> > I'm
> > > saying it's a choice you have to think about. There are
> > Not every
> > > programming decision can be made by prescription.
> >
> > I didn't single out any one person when I said "they" break their
> > rules. By your own admission here you don't have rules but
> > have what I'd consider loose guidelines.
> They're not really as loose as they may seem. I pretty much always
> invariants and preconditions. I'm just unwilling to pass judgement
> someone who thinks they stand a better chance of recovery in a
> mission-critical application by turning all precondition violations
> exceptions for the shipping product. IMO, a precondition violation
> always means some program invariant is broken, so recovery is
> 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
> > 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at