Re: [boost] Re: any_function (callback) library

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-04-12 09:15:01

> > > > 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.
> >
> > That's incorrect. You obviously didn't try it.
>
> Whoa.  Slow down there.  This comes very close to flame material,

Well, no offense intended...

> especially considering I *DID* check it (VC 6, SP 4), and I'm correct
> that the catch block is never entered.  Sorry.

Did you use the compiler settings specified above? If so, I am at a loss to
explain our differing results. I am also using VC6 SP 4.

> > It throws a structured
> > exception which raises JIT debugging. First you get an abort/retry
> dialog.
> > Then you choose "Retry" to enter JIT debugging. Then it prints "hi
> there" to
> > standard out as the structured exception enters the catch block.
> Then the
> > JIT debugger fails to come up because the exception isn't re-thrown.
>
> Not on my tests it doesn't.  However, I ran this test under the
> debugger.

OH. Then you're not going to see the same issues as one sees for JIT
debugging. But I think if you continue from the program "halt" you will see
the "hi there" message and a return code of 0.

> Possibly the behavior you speak of only occurs when run
> outside of the debugger.

Yes.

> That would be an interesting case, but one
> that I've never encountered since I only run debug builds through the
> debugger.

That explains it.

> > > 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.
> >
> > ...mmm, I don't think I agree. Would anybody really do this in C++?
> >
> > for (std::size_t i = 0;; ++i)
> > {
> >     T* x;
> >     try {
> >         x = &v.at(i);
> >     }
> >     catch(std::out_of_range) {
> >         break;
> >     }
> >     f(*x);
> > }
>
> Yes, people really do that, though this particular case is so simple
> that a rewrite can easily be done to insure out of range checks are
> not needed.  So I'd expect qualified C++ programmers would avoid
> this.  Then again, I'd expect qualified language X programmers to
> avoid it as well (and have seen them do so).

What I'm trying to say is that the mechanism is built into the python
language. When you write

  for x in s:
    print x

it uses an exception under the covers to detect the end of the sequence.
Python exceptions are no less efficient than any other control structure.

-Dave