From: williamkempf_at_[hidden]
Date: 2001-04-13 08:40:11
--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> > > > > 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.
Same settings.
> > > 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.
I continued from the assertion line and the catch was never entered.
> > 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.
Regardless, people *do* use exceptions in the same manner here, and
frankly this would be the only purpose for at() throwing.
Bill Kempf