Xref: utzoo gnu.g++.help:156 comp.lang.c++:10458
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!att!dptg!ulysses!andante!alice!bs
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: gnu.g++.help,comp.lang.c++
Subject: Re: Incompatible changes in C++
Summary: 'taint easy or simple
Message-ID: <11647@alice.att.com>
Date: 20 Nov 90 03:18:01 GMT
References: <9011171750.AA29372@mole.ai.mit.edu> <11635@alice.att.com> <1990Nov19.195128.18538@zoo.toronto.edu>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 27



Henry Spencer at U of Toronto Zoology writes:

 > What concerns me is exception handling.

That is indeed a legitimate cause for concern. I share it up to a point.
It is the least tried aspect of the language as currently defined and
the one we ought to worry the most about.

We built partly on experience from the Clu, Modula2+, Modula3 sequence
of languages, partly on experience with faking exceptions in C++, and
partly on an experimental C++ with exception handling implementation
at Sun. So even though we don't have as much experience as we would
like we are not without practical experience with exceptions handling
in the context of C++.

There was another concern: There was a strong push from some users and
from some implementors: Agree on something NOW or else we will go our
own way. Caught between a rock and a hard place it seemed most sensible
for us all to agree to do the same thing. Anything else would guarantee
divergence.

I would have preferred a couple of years to experiement with exception
handling on a larger scale, but you can't always get exactly what you
want. People were NOT willing to wait with standardization and people
were NOT willing to define C++ without exception handling.