Re: Why do some code bases don't use exceptions?
On Nov 21, 2:57 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
James Kanze <james.ka...@gmail.com> wrote in
news:f37f1e13-cdcc-4144-
b526-364f2bcf6...@s31g2000yqs.googlegroups.com:
On Nov 17, 8:43 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
krel <k...@example.invalid> wrote innews:hduq8e$4f9$1@news.eternal-
september.org:
and badly designed feature".
In C++, there are surprisingly few "broken and badly
designed features".
That's very arguable. The question isn't so much whether
C++ does it right; it's usually a question of other
languages not supporting it at all.
Non-empty exception specifications are one example,
Broken and badly designed, or simply a more or less good
solution without a problem?
I would say broken and badly designed as they solve even the
perceived problem inadequately (app termination is not an
adequate solution imo, and catch(...) is better than using a
global unexpected handler).
What is the perceived problem? And why is aborting (as a
default behavior) a bad solution? Violating an exception
specification is a contract violation, so aborting *is* about
the only appropriate default behavior. The question is: what
problem is solved by supporting contracts in which a function
is allowed to throw a limited set of exceptions (as opposed to
no exception).
I think the problem of having unexpected exceptions is real,
but there is already a better solution (catch(...)).
They don't detect the error when it occurs. And they result in
stack unwinding occurring---something you definitely don't want
if the exception is a contract violation.
the "most-vexing-c++- parse" another. The latter was kept
for C compatibility, but I strongly suspect the amount of C
code saved this way is very close to zero.
Are you kidding? Take a look at any of the C headers on
your machine. How many systematically use "extern" before
function declarations, and how many just count on the fact
that a function declaration is always "extern", unless
specified otherwise.
Hmm, I was thinking of a line like
S s(S());
where the inner S() is interpreted as a "function returning S
taking no arguments" (quotes
fromhttp://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/56509...
5).
Instead, this could be written in a more or less equivalent,
yet less ambiguous way as:
S s(S(*)());
or more clearly, using typedefs.
This example, yes. Changing it, however, would involve breaking
C compatibility. I was thinking of the common case:
S s(S(a));
, where a is an already existing variable. Regretfully, most
headers are full of this sort of thing, rather than e.g.:
extern S s(S(a));
(if they are declaring a function).
Again, in this simple case, you could drop the extra parentheses
in the function decaration, but banning an extra set of
encapsulating parentheses would complicate the grammar
excessively.
What I doubted was that there are any real-world headers
containing function declarations like
A x(B(), C(), D());
If this syntax were changed to mean object definition instead,
the whole class of user errors could be eliminated - or am I
seriously mistaken here?
Thinking about it: one could probably get away with 1) dropping
the implicit conversion of the parameter type for functions, and
2) banning outermost parentheses. It's an idea, but you'd need
some volenteer to come up with the wording for point 2, since it
means redefining the grammar for type expressions in some way.
--
James Kanze