Re: [boost] Re: In-place construction for variant

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-11-04 15:30:27

--- David Abrahams <dave_at_[hidden]> wrote:
[...]
> 
> Why?
> 
> Rather than wait for your answer, because I really need to quit this
> thread and spend my attention elsewhere, I'll anticipate it.  
> 
>   I think you mean that exceptions whose types you don't know, and
>   which indicate some fundamentally broken state of the system, might
>   be thrown.  I think you're worried that catch(...) will stop these
>   exceptions and your program will continue ahead as though nothing
>   had gone wrong.

That is correct.

> 
> If I've anticipated wrong, I'm sorry, but you'll have to get your
> questions answered elsewhere because I'm out of time.  

No need to give excuses. :)

> If not, recall
> that the paper was written about the process of standardizing C++ and
> not about specific operating systems and their degenerate
> fault-handling schemes (**).  Here are the problems with your
> assertion, from the point-of-view of standard C++:
> 
>   1. There's no reason to think that a fundamentally broken state of
>      the system leads to a C++ exception, any more than it leads
>      directly to launching a missile or reformatting your hard drive.

True.

> 
>   2. In your code below, the same reasoning means that if p->f()
>      causes undefined behavior, you have no right to expect that
>      execution will reach the catch(...) clause; the program is just
>      as likely to end up executing "delete p".  Undefined behavior
>      means just that: the behavior is arbitrary.

True.

> 
> > The first precondition is that you have to know what exceptions a
> > "correct" implementation of a class can possibly generate. Let's
> > assume that that the correct method, my_type::f() can generate only
> > one exception, out_of_memory and my_type provides basic guarantees.
> 
>   2a. (corrolary) Undefined behavior may end up throwing one of those
>       exceptions which you think only a "correct" implementation of
>       your class can generate.

True.

> 
> <snip>
> 
> (**) if you want to read about those issues, see the "what about
>      programmer errors?" section of
>      http://www.boost.org/more/error_handling.html.  Believe me, they
>      have been considered.

Excellent!

"I reluctantly concede this point to Hillel Y. Sims, who beat it into me (<wink>): until all OSes
are "fixed", if every exception were derived from std::exception and everyone substituted
catch(std::exception&) for catch(...), the world would be a better place.

Sometimes, catch(...), is still the most appropriate pattern, in spite of bad interactions with
OS/platform design choices. If you have no idea what kind of exception might be thrown and you
really must stop unwinding it's probably still your best bet. One obvious place where this occurs
is at language boundaries."

I take it as you concede to me then. I didn't know about your 
disucussion with Hillel Y. Sims but my main point seems to be 
the same.

[...]
> In an incorrect program, anything can happen including direct
> launching of a missile without throwing an exception.

True. So what is conclusion.

[...]
> 
> In standard C++, yes, you can.

I was talkin about real life programming all along.
I agree with the theory.

[...]
> > What do you mean by "rest of us"?
> 
> Those of us who have not only yesterday begun to come to grips with
> the principles of using invariants in stateful programs.  I don't
> mean to be pretentious, but it's a bit early for you to start
> "correcting the experts".

Sounds like a political party. :)
No offence, but it seems like many "experts" are confused
about invariants.  No offense, but real experts are
actually *looking* for corrections and trying to understand
what other people are trying to say.

[...]
> 
> Using the destructor of an automatic object to restore invariants is
> probably a better in most cases.

Many boost libraries use catch(...) internally.
If destructors are better should it be changed
should it be included as part of the review process?
[...]
> 
> A better solution, if your OS is prone to throwing exceptions from
> hardware faults or other "undefined behavior" conditions, is to
> instruct the OS to abort() immediately by inserting handlers at the
> lowest level, before any unwinding can occur.  In order to enter your
> catch(...) block the compiler must unwind the stack, executing
> destructors, which hardly constitutes an "immediate exit".  If you
> can't do that, you're usually much better off allowing those
> exceptions to leak out of the program completely, since in that
> situation many compilers will do no stack unwinding at all.
> 

Great! I agree. See my previous comment.

Eugene

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree