Re: any_function (callback) library

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