Doug McIlroy on exception handling
Andrew Simmons
"The Design and Evolution of C++", I came across the following
passage:
"A notable exception to this agreement was Doug McIlroy, who stated
that the availabilty of exception handling would make systems less
reliable because library writers and other programmers will throw
exceptions rather than try to understand and handle problems. Only
time will tell to what extent Doug's prediction will be true."
The book was published in 1994, and I would think that Mr McIlroy
expressed his opinion in the early 1990s, so I would guess that enough
time has passed to come to at least a preliminary judgement. Based on
my own experience, I would be inclined to say that Mr McIlroy had got
it absolutely right. In many programs I have seen, the general rule
seems to be that if there is a problem, you can just throw an
exception and assume someone else will handle it - the result is that
a good number of programs terminate after printing a cryptic message
about an unhandled exception. I would be interested to hear other
people's views on how Mr McIlroy's prediction has turned out.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
James Kanze
news:<64055d11.02101...@posting.google.com>...
I think that Doug worked with an exceptionally serious group of
programmers. I suspect (and one of the major arguments in favor of
exceptions is) that far too many people ignore error conditions
completely. I've seen a lot of code, for example, in which fclose
fails, but the code continues as if everything was correctly written to
the disk. In such cases, an uncaught exception and program termination
is an improvement.
My impression is that no one has adopted exceptions with more enthusiasm
that library implementors, because finally, the users couldn't ignore
their error messages (and then blame them anyway when the results
weren't correct).
The real problems with exceptions only affect the people who did serious
error handling. If your code checked every new for null, and did some
special error handling, exceptions broke it. More importantly, it
wasn't easy to fix, because the original code almost certainly wasn't
exception safe. (The code which didn't check the errors before probably
wasn't exception safe either, but in that case, it was a question of
going from broken to broken, so who cares.)
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
Ira Baxter
"Andrew Simmons" <and...@mbmnz.co.nz> wrote in message
news:64055d11.02101...@posting.google.com...
> "A notable exception to this agreement was Doug McIlroy, who stated
> that the availabilty of exception handling would make systems less
> reliable because library writers and other programmers will throw
>
> ... I would think that Mr McIlroy
> expressed his opinion in the early 1990s, so I would guess that enough
> time has passed to come to at least a preliminary judgement. Based on
> my own experience, I would be inclined to say that Mr McIlroy had got
> it absolutely right. In many programs I have seen, the general rule
> seems to be that if there is a problem, you can just throw an
> exception and assume someone else will handle it - the result is that
> a good number of programs terminate after printing a cryptic message
> about an unhandled exception. I would be interested to hear other
> people's views on how Mr McIlroy's prediction has turned out.
You can have a friendlier scheme to handle "unhandled" exceptions.
Our PARLANSE language (an internal language we use to build
program analysis tools, nothing to do with C++, just illustrates
the point) treats exceptions essentially as string function values
with a separate set of arguments. Exception handlers can check
for specific exceptions, can inspect the exception arguments if desired,
etc.
The exception-propagation logic records a trace of calls that
the exception unwinds through. The implicit top-level
exception handler (the one behind the "call to main()")
will apply the string function to its arguments, producing
an error message which is as meaningful as the exception-definer
wishes to make, plus a call backtrace.
So you get a decent error message, and a way to track it back
to the point of origin.
We can argue about whether programmers still just
throw exceptions without "understanding the problem".
I think any procedure with a contract is reasonably allow
to complain that its contract isn't met. No understanding
required.
--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com .
apm
> "The Design and Evolution of C++", I came across the following
> passage:
>
> "A notable exception to this agreement was Doug McIlroy, who stated
> that the availabilty of exception handling would make systems less
> reliable because library writers and other programmers will throw
> exceptions rather than try to understand and handle problems. Only
> time will tell to what extent Doug's prediction will be true."
>
> The book was published in 1994, and I would think that Mr McIlroy
> expressed his opinion in the early 1990s, so I would guess that enough
> time has passed to come to at least a preliminary judgement. Based on
> my own experience, I would be inclined to say that Mr McIlroy had got
> it absolutely right.
I agree with you. At least one coding standard (Industrial strength
C++ by Nyquist) actually has this as a coding standard. Sigh.
-Andrew Marlow.
Robert Klemme
Ira Baxter schrieb:
> You can have a friendlier scheme to handle "unhandled" exceptions.
> Our PARLANSE language (an internal language we use to build
> program analysis tools, nothing to do with C++, just illustrates
> the point) treats exceptions essentially as string function values
> with a separate set of arguments.
i'm not sure whether i could follow you completely. is an
exception a function? or the result of a function invocation?
> Exception handlers can check
> for specific exceptions, can inspect the exception arguments if desired,
> etc.
> The exception-propagation logic records a trace of calls that
> the exception unwinds through. The implicit top-level
> exception handler (the one behind the "call to main()")
> will apply the string function to its arguments, producing
> an error message which is as meaningful as the exception-definer
> wishes to make, plus a call backtrace.
>
> So you get a decent error message, and a way to track it back
> to the point of origin.
judging from the result this sounds quite similar to what java
provides: textual stack trace, a message and arbitrary more
data. the new standard even supports exception chaining, i.e.
wrapping an exception with another exception. did i get it
right?
regards
robert
Roger Orr
news:d1a33011.02101...@posting.google.com...
> and...@mbmnz.co.nz (Andrew Simmons) wrote in message
news:<64055d11.02101...@posting.google.com>...
> > While perusing the chapter on exception handling in Mr Stroustrup's
> > "The Design and Evolution of C++", I came across the following
> > passage:
> >
> > "A notable exception to this agreement was Doug McIlroy, who stated
> > that the availabilty of exception handling would make systems less
> > reliable because library writers and other programmers will throw
> > exceptions rather than try to understand and handle problems. Only
> > time will tell to what extent Doug's prediction will be true."
> >
I think the biggest problem with exceptions is the non-obvious flow of
control.
This catches out even experts from time to time, but in my experience many
(if not most) users of C++ simply don't notice the problem exists.
Not that many C++ programmers seems to see any possible problems with code
like:-
int SomeClass::fred()
{
++in_use;
call_something();
--in_use;
}
although I suspect most of this newgroup would...
Roger Orr
--
MVP in C++ at www.brainbench.com
Roger Schlafly
> > "A notable exception to this agreement was Doug McIlroy, who stated
> > that the availabilty of exception handling would make systems less
> > reliable because library writers and other programmers will throw
> > exceptions rather than try to understand and handle problems.
> that library implementors, because finally, the users couldn't ignore
> their error messages (and then blame them anyway when the results
> weren't correct).
Too much enthusiam, maybe. I just found that Boost.org added a
Date class, and I naively thought that a nice clean date class would
be useful to me. I was wrong -- this monster has 60 include files!
I cannot even find the function I want. But worse, the library
throws exceptions. So I cannot use it unless I understand what
exceptions can be thrown, and write exception-safe code for
catching those exceptions. McIlroy could be correct and this
approach could lead to less reliable systems.
James Kanze
news:<aohg8s$70p$1...@slb6.atl.mindspring.net>...
> "James Kanze" <ka...@gabi-soft.de> wrote
> > > "A notable exception to this agreement was Doug McIlroy, who
> > > stated that the availabilty of exception handling would make
> > > systems less reliable because library writers and other
> > > programmers will throw exceptions rather than try to understand
> > > and handle problems.
> > My impression is that no one has adopted exceptions with more
> > enthusiasm that library implementors, because finally, the users
> > couldn't ignore their error messages (and then blame them anyway
> > when the results weren't correct).
> Too much enthusiam, maybe. I just found that Boost.org added a Date
> class, and I naively thought that a nice clean date class would be
> useful to me. I was wrong -- this monster has 60 include files! I
> cannot even find the function I want. But worse, the library throws
> exceptions. So I cannot use it unless I understand what exceptions can
> be thrown, and write exception-safe code for catching those
> exceptions. McIlroy could be correct and this approach could lead to
> less reliable systems.
I sort of agree. But there is a definite problem: far too many
programmers ignore error conditions entirely. If the programmer ignores
a return code, everything seems to work, he gets wrong results, and he
blames the library provider. If he ignores an exception, it's clear
that he did something wrong.
Globally, exceptions improve the quality of bad programs, but create no
end of problems for good programs. Since library writers know that most
programs are poorly written, they go with exceptions.
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Hyman Rosen
> I naively thought that a nice clean date class
Date and time handling is complicated. A comprehensive
library has many issues to deal with.
> But worse, the library throws exceptions. So I cannot use it
> unless I understand what exceptions can be thrown
How is this any different than if the functions returned
error codes? You would feel free to use them without
understanding what the error codes meant? That would make
the program more reliable?
Bob Bell
news:<aohqnu$jqf$1$8300...@news.demon.co.uk>...
> "apm" <ap...@student.open.ac.uk> wrote in message
> news:d1a33011.02101...@posting.google.com...
> > and...@mbmnz.co.nz (Andrew Simmons) wrote in message
> news:<64055d11.02101...@posting.google.com>...
> > > While perusing the chapter on exception handling in Mr
Stroustrup's
> > > "The Design and Evolution of C++", I came across the following
> > > passage:
> > >
> > > "A notable exception to this agreement was Doug McIlroy, who
stated
> > > that the availabilty of exception handling would make systems
less
> > > reliable because library writers and other programmers will throw
> > > exceptions rather than try to understand and handle problems.
Only
> > > time will tell to what extent Doug's prediction will be true."
> > >
>
>
> I think the biggest problem with exceptions is the non-obvious flow of
> control.
I used to see this argument used against virtual functions:
"I think the biggest problem with virtual functions is the non-obvious
flow of control."
It's a red herring, if you ask me.
Bob
Igor Ivanov
(See also my reply to Roger Schlafly).
The program terminates with a cryptic message because it was not
debugged and written properly and the exception was not handled where
it should.
McIlroy's opinion proved to be wrong.
One robust example using exceptions is the STL.
Regards
Igor
Roland Pibinger
<rog...@mindspring.com> wrote:
>"James Kanze" <ka...@gabi-soft.de> wrote
>> > "A notable exception to this agreement was Doug McIlroy, who
stated
>> > that the availabilty of exception handling would make systems less
>> > reliable because library writers and other programmers will throw
>> > exceptions rather than try to understand and handle problems.
>> My impression is that no one has adopted exceptions with more
enthusiasm
>> that library implementors, because finally, the users couldn't ignore
>> their error messages (and then blame them anyway when the results
>> weren't correct).
>
>Too much enthusiam, maybe. I just found that Boost.org added a
>Date class, and I naively thought that a nice clean date class would
>be useful to me. I was wrong -- this monster has 60 include files!
>I cannot even find the function I want. But worse, the library
>throws exceptions. So I cannot use it unless I understand what
>exceptions can be thrown, and write exception-safe code for
>catching those exceptions.
That's the reason why exception specifications are important, even
though some of the gurus deprecate them.
Best regards,
Roland Pibinger
Igor Ivanov
news:<aohg8s$70p$1...@slb6.atl.mindspring.net>...
> > > "A notable exception to this agreement was Doug McIlroy, who
stated
> > > that the availabilty of exception handling would make systems
less
> > > reliable because library writers and other programmers will throw
> > > exceptions rather than try to understand and handle problems.
> > My impression is that no one has adopted exceptions with more
enthusiasm
> > that library implementors, because finally, the users couldn't
ignore
> > their error messages (and then blame them anyway when the results
> > weren't correct).
>
> Too much enthusiam, maybe. I just found that Boost.org added a
> Date class, and I naively thought that a nice clean date class would
> be useful to me. I was wrong -- this monster has 60 include files!
> I cannot even find the function I want. But worse, the library
> throws exceptions. So I cannot use it unless I understand what
> exceptions can be thrown, and write exception-safe code for
> catching those exceptions. McIlroy could be correct and this
> approach could lead to less reliable systems.
>
I think you are confusing two completely different problems: lack of
documentation and error handling. I believe that the Date class you
are talking about throws exceptions when e.g. its member function
cannot return a meaningful result etc. Would you rather prefer that it
just silently returned a meaningless number? Or that it would have an
additional "error code" argument everywhere and you you would have
plenty of chance to forget to check it? And how would either of these
options make a system more reliable?
Unfortunately, poor documentation is a widespread problem, especially
with free software. It's somewhat related to "you get what you pay
for", though not one-to-one. (Disclaimer: I have no idea about the
documentation quality of the Date class or the Boost library, so this
statement may not apply to this case.)
Regards
Igor
David Abrahams
I've stayed out of this conversation 'till now, because it mostly
reads like a troll. However, you've now succeeded in getting my
attention.
> I sort of agree. But there is a definite problem: far too many
> programmers ignore error conditions entirely. If the programmer
> ignores a return code, everything seems to work, he gets wrong
> results, and he blames the library provider. If he ignores an
> exception, it's clear that he did something wrong.
>
> Globally, exceptions improve the quality of bad programs, but create no
> end of problems for good programs.
That's completely unfair. Exceptions don't cause any problems for good
programs which were written to work with exceptions in the first
place. But maybe the use of exceptions in the first place conflicts
with your definition of "good program?"
> Since library writers know that most programs are poorly written,
> they go with exceptions.
And this is even more unfair, a potshot at library providers. I don't
"go with exceptions" because it helps me shift the blame to the user
as you imply. I use exceptions because:
a. they make it easier to properly handle the kinds of errors that
can occur in my code.
b. They lead to more natural interfaces and usage.
c. They allow me to implement more efficient algorithms
d. They lead to more-expressive implementations which clearly
separate mainline code from the code used to abort operations in
case of errors.
e. I don't enjoy living in the dark ages, writing twice as much code
to accomplish the same thing as I would have otherwise, and being
more-likely to make a mistake doing so.
--
David Abrahams
da...@boost-consulting.com * http://www.boost-consulting.com
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html
Herb Sutter
>>Too much enthusiam, maybe. I just found that Boost.org added a
>>Date class, and I naively thought that a nice clean date class would
>>be useful to me. I was wrong -- this monster has 60 include files!
>>I cannot even find the function I want. But worse, the library
>>throws exceptions. So I cannot use it unless I understand what
>>exceptions can be thrown, and write exception-safe code for
>>catching those exceptions.
Yes, the last is generally true of C++ libraries.
>That's the reason why exception specifications are important, even
>though some of the gurus deprecate them.
No, a non sequitur.
Exception specifications are not for documentation of what exceptions an
operation could throw. Documentation is for documentation of what exceptions
an operation could throw. Exception specifications are for unceremoniously
shooting your program in the head, resulting in instant death with no
opportunity even for cleanup or graceful shutdown, at runtime long after
you've shipping -- and usually in front of your most important customer.
Exception specifications will help you little or not at all cases like the
above. Reading the documentation, or improving the documentation as the case
may be, will help a lot.
Boost itself (many of whose members used to agree with you) has coding
standards that strongly discourage exception specifications for very good
reasons. For a detailed treatment of this subject, see also my recent CUJ
article now available online:
"A Pragmatic Look at Exception Specifications"
C/C++ Users Journal, 20(7), July 2002.
http://www.gotw.ca/publications/mill22.htm
Herb
---
Herb Sutter (www.gotw.ca)
Convener, ISO WG21 - Secretary, ANSI J16 (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
C++ community program manager, Microsoft (www.gotw.ca/microsoft)
Check out "THE C++ Seminar" - Oct 28-30, 2002 (www.thecppseminar.com)
Herb Sutter
>Globally, exceptions improve the quality of bad programs, but create no
>end of problems for good programs. Since library writers know that most
>programs are poorly written, they go with exceptions.
James, a forceful, unsupported, and IMO completely wrong assertion like this
is very uncharacteristic of you. Is this really what you meant to say?
Herb
---
Herb Sutter (www.gotw.ca)
Convener, ISO WG21 - Secretary, ANSI J16 (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
C++ community program manager, Microsoft (www.gotw.ca/microsoft)
Check out "THE C++ Seminar" - Oct 28-30, 2002 (www.thecppseminar.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Christophe Lephay
bqvtquk1cectc49a1...@4ax.com...
> "A Pragmatic Look at Exception Specifications"
> C/C++ Users Journal, 20(7), July 2002.
> http://www.gotw.ca/publications/mill22.htm
It seems to me that exceptions specifications may be seen to tell the
compiler :
1- what kind of exceptions may be thrown within the function ;
2- what kind of exceptions must not be thrown from within the function.
Of course 1- and 2- are very similar, but won't a keyword like nothrow( exc.
spec. ) be usefull to specify clearly that a specific exception [list] must
not propagate ?
Christophe Lephay
Christophe Lephay
> On 16 Oct 2002 16:56:42 -0400, ka...@gabi-soft.de (James Kanze) wrote:
> >Globally, exceptions improve the quality of bad programs, but create no
> >end of problems for good programs. Since library writers know that most
> >programs are poorly written, they go with exceptions.
>
> James, a forceful, unsupported, and IMO completely wrong assertion like
this
> is very uncharacteristic of you. Is this really what you meant to say?
Maybe was he refering to people who didn't check return values and who
probably go on without handling exceptions...
We may discuss about the fact that people *globally* handle exceptions in
their code or not...
Christophe Lephay
James Kanze
news:<8k0uqusu21ds2evl0...@4ax.com>...
> On 16 Oct 2002 16:56:42 -0400, ka...@gabi-soft.de (James Kanze) wrote:
> >Globally, exceptions improve the quality of bad programs, but create
> >no end of problems for good programs. Since library writers know
> >that most programs are poorly written, they go with exceptions.
> James, a forceful, unsupported, and IMO completely wrong assertion
> like this is very uncharacteristic of you. Is this really what you
> meant to say?
It didn't come out quite what I meant, no. I was thinking of the
particular context of existing code from the pre-exception days. The
shift to exceptions broke a lot of previously correct code, whereas it
typically improved poorly written code, causing it to terminate, rather
than to silently give wrong results. Obviously (I hope), exceptions
don't break code which is correctly written with exceptions in mind.
(I'll avoid the question of whether it is easier to write correct code
in the presence of exceptions, or using return codes:-). Except to say
that neither are particularly easy; handling errors correctly is one of
the most difficult aspects of programming, regardless of how you report
them.)
As for the second sentence, it was really more of a cheap joke, and I
should have put a smiley on it. If I were a library writer, I think
that I would consider the fact that user code cannot ignore my error
messages an advantage. But I'm sure it's not the only issue real
library authors consider.
And I hope David will take this as an appology as well. It certainly
wasn't my intent to insult anyone. It wasn't even my intent to make a
statement for or against exceptions in new programs, and I should have
made the context I was thinking of clear.
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Alexander Terekhov
Herb Sutter wrote:
[...]
> Boost itself (many of whose members used to agree with you) has coding
> standards that strongly discourage exception specifications for very good
> reasons. For a detailed treatment of this subject, see also my recent CUJ
> article now available online:
>
> "A Pragmatic Look at Exception Specifications"
> C/C++ Users Journal, 20(7), July 2002.
> http://www.gotw.ca/publications/mill22.htm
And for a MORE detailed "treatment of this subject" see also >>/my/<<
recent posts on this subject (and on Herb's article/"morals") that
are now [still ;-) ] available online on Google in this {sub-}thread:
http://groups.google.com/groups?threadm=m.collett-1375FF.11191019072002%40lust.ihug.co.nz
(Subject: Re: Is internal catch-clause rethrow standard?)
[...]
> Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
regards,
alexander.
--
http://www.chillingeffects.org/dmca512/notice.cgi?NoticeID=320
Peter Dimov
> On 15 Oct 2002 18:56:15 -0400, "Roger Schlafly"
> <rog...@mindspring.com> wrote:
>
> >Too much enthusiam, maybe. I just found that Boost.org added a
> >Date class, and I naively thought that a nice clean date class would
> >be useful to me. I was wrong -- this monster has 60 include files!
> >I cannot even find the function I want. But worse, the library
> >throws exceptions. So I cannot use it unless I understand what
> >exceptions can be thrown, and write exception-safe code for
> >catching those exceptions.
I'll bite.
"But worse, the functions do something! So I cannot use them unless I
understand what they do!"
> That's the reason why exception specifications are important, even
> though some of the gurus deprecate them.
Nope. You might believe that they are important, but that doesn't make
them important in general.
Consider the statement above:
> >throws exceptions. So I cannot use it unless I understand what
> >exceptions can be thrown, and write exception-safe code for
> >catching those exceptions.
Note the assertion that exception-safe code must catch those
exceptions, which is plainly false. Exception-safe code rarely catches
anything. Having an exception specification available doesn't
magically make you proficient in writing exception-safe code.
James Kanze
news:<d117aff2.02101...@posting.google.com>...
> and...@mbmnz.co.nz (Andrew Simmons) wrote in message
> news:<64055d11.02101...@posting.google.com>...
> > While perusing the chapter on exception handling in Mr Stroustrup's
> > "The Design and Evolution of C++", I came across the following
> > passage:
> > "A notable exception to this agreement was Doug McIlroy, who stated
> > that the availabilty of exception handling would make systems less
> > reliable because library writers and other programmers will throw
> > exceptions rather than try to understand and handle problems. Only
> > time will tell to what extent Doug's prediction will be true."
> > The book was published in 1994, and I would think that Mr McIlroy
> > expressed his opinion in the early 1990s, so I would guess that
> > enough time has passed to come to at least a preliminary
> > judgement. Based on my own experience, I would be inclined to say
> > that Mr McIlroy had got it absolutely right. In many programs I
> > have seen, the general rule seems to be that if there is a problem,
> > you can just throw an exception and assume someone else will handle
> > it - the result is that a good number of programs terminate after
> > printing a cryptic message about an unhandled exception. I would be
> > interested to hear other people's views on how Mr McIlroy's
> > prediction has turned out.
> The program terminates with a cryptic message because it was not
> debugged and written properly and the exception was not handled where
> it should.
So what else is new? That's exactly what Doug McIlroy wrote : that a
good number of programs will terminate after printing a cryptic message
about an unhandled exception.
> McIlroy's opinion proved to be wrong.
I think that it needs nuancing. I'm not sure that it has been proven
one way or another. The actual statement quoted above ("That a good
number of program terminate after printing a cryptic message about an
unhandled exception") is certainly correct. It leaves open a number of
questions, however:
- Is he referring to new programs, or to existing programs?
Introducing exceptions into a correct, pre-exception program will
break it. There is no doubt about that, and I can remember some
discussion in the committee concerning the fact that changing new to
throw broke the "correct" programs that existed, while improving
those that were incorrect (because they ignored error cases).
The issues surrounding new programs are much more complex, and are
really part of the second question.
- What happens without exceptions? A program can be correctly written
with or without exceptions. Which is easier is an open question,
but what is certain is that a correct program won't terminate with a
cryptic message due to an uncaught exception, any more than it will
continue using wrong data due to an unchecked return code. Simply
because by definition, the program isn't correct if that happens.
So if McIlroy was talking about new programs, he can only be talking
about incorrect programs. (Regretfully, a good number of programs
ARE incorrect programs.) Again, in this case, his statement is
quite correct. On the other hand, one could very easily argue that
terminating with a cryptic error message is still preferrable to
continuing and silently giving a wrong answer, which is what will
happen with unchecked return codes.
- Finally, the text in the posting seems to suggest that somehow
library writers will be raising exceptions in cases where they
wouldn't have reported an error at all otherwise. I'm not at all
clear about what those cases might be. If there really is an error,
and if the library didn't check it without exceptions, we are in the
preceding case of continuing with wrong data. And I can't imagine
library writers throwing exceptions when there wasn't anything
wrong, just because they happen to feal like it; a library written
by such a person would have so many problems with it, exceptions or
no, that no one would use it.
> One robust example using exceptions is the STL.
Actually, the STL is more an example of a library which avoids
exceptions. About the only possible exception in the original STL was
bad_alloc, and that isn't generated by STL directly (and probably wasn't
present in the original STL either, since the original STL dates from an
epoch when new returned a null pointer).
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Sergey P. Derevyago
> > Too much enthusiam, maybe. I just found that Boost.org added a Date
> > class, and I naively thought that a nice clean date class would be
> > useful to me. I was wrong -- this monster has 60 include files!
need horse (I speak about uncontrolled evolution rather than "malicious
intent", but from the end user's point of view...).
> > I
> > cannot even find the function I want. But worse, the library throws
> > exceptions. So I cannot use it unless I understand what exceptions can
> > be thrown, and write exception-safe code for catching those
> > exceptions.
Statically checked nothrow guarantees can really help here, IMHO.
> > McIlroy could be correct and this approach could lead to
> > less reliable systems.
>
> I sort of agree. But there is a definite problem: far too many
> programmers ignore error conditions entirely.
Do you mean _professional_ programmers? AFAIK even an artless code review can
easily catch this particular problem.
> If the programmer ignores
> a return code, everything seems to work, he gets wrong results, and he
> blames the library provider.
... until someone takes a look at the code :)
> If he ignores an exception, it's clear
> that he did something wrong.
Nevertherless, a sloppy coder can write something like this
void f()
{
try {
f();
g();
h();
}
catch (...) {
// Wow, g() has thrown!
}
}
while the source of the exception is f() or h(). And it's the issue with long
try blocks.
> Globally, exceptions improve the quality of bad programs, but create no
> end of problems for good programs.
IMHO "the quality of bad programs" can't be _significantly_ improved by any
automatic process or tool. Computer is just a bicycle for our mind -- you have
to pedal.
> Since library writers know that most
> programs are poorly written, they go with exceptions.
Which hides the problem, only.
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net
Roland Pibinger
>On 17 Oct 2002 12:54:51 -0400, rpb...@yahoo.com (Roland Pibinger) wrote:
>>>Too much enthusiam, maybe. I just found that Boost.org added a
>>>Date class, and I naively thought that a nice clean date class would
>>>be useful to me. I was wrong -- this monster has 60 include files!
>>>I cannot even find the function I want. But worse, the library
>>>throws exceptions. So I cannot use it unless I understand what
>>>exceptions can be thrown, and write exception-safe code for
>>>catching those exceptions.
>
>Yes, the last is generally true of C++ libraries.
>
>>That's the reason why exception specifications are important, even
>>though some of the gurus deprecate them.
>
>No, a non sequitur.
>
>Exception specifications are not for documentation of what exceptions an
>operation could throw. Documentation is for documentation of what exceptions
>an operation could throw. Exception specifications are for unceremoniously
>shooting your program in the head, resulting in instant death with no
>opportunity even for cleanup or graceful shutdown, at runtime long after
>you've shipping -- and usually in front of your most important customer.
Not if you expect the unexpected and add std::bad_exception to all
exception specifications (see also Stroustrup, TCPL, 3rd ed, 14.6.3
Mapping Exceptions), e.g.
class Date {
void set (int year, int month, int day)
throw (std::out_of_range, std::bad_exception);
// ...
};
This is conceptually similar (not identical) to the distinction in
Java between Exception(s) and Error(s), or alternatively between
checked and unchecked exceptions. IMO std::bad_exception should be
added to all exception specifications implicitly by the language.
>Exception specifications will help you little or not at all cases like the
>above. Reading the documentation, or improving the documentation as the case
>may be, will help a lot.
If you know what exceptions can be thrown in your code you can write
both, a documentation and an exception specification, otherwise
neither.
>Boost itself (many of whose members used to agree with you) has coding
>standards that strongly discourage exception specifications for very good
>reasons. For a detailed treatment of this subject, see also my recent CUJ
>article now available online:
>
> "A Pragmatic Look at Exception Specifications"
> C/C++ Users Journal, 20(7), July 2002.
> http://www.gotw.ca/publications/mill22.htm
Good arguments (of course), mores non sequintur.
What are bad_exception[s] good for except for bad exceptions?
Best regards,
Roland Pibinger
David Abrahams
> And I hope David will take this as an appology as well.
Accepted.
--
David Abrahams
da...@boost-consulting.com * http://www.boost-consulting.com
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Roland Pibinger
>I'll bite.
>Consider the statement above:
Exception specifications are part of the contract between user and
implementor (as a user I want to know the full contract).
The user decides whether he immediately catches the exception or lets
it bubble up.
Best regards,
Roland Pibinger
Sergey P. Derevyago
> > One robust example using exceptions is the STL.
> Actually, the STL is more an example of a library which avoids
> exceptions.
> About the only possible exception in the original STL was
> bad_alloc, and that isn't generated by STL directly (and probably wasn't
> present in the original STL either, since the original STL dates from an
> epoch when new returned a null pointer).
BTW, did the original vector have at()?
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Andrew Simmons
>
> So what else is new? That's exactly what Doug McIlroy wrote : that a
> good number of programs will terminate after printing a cryptic message
> about an unhandled exception.
>
It would be unfair to Doug McIlroy to let this stand uncorrected,
since it was I, not he, who made the statement referred to. The only
knowledge I have about Mr McIlroy's views are contained in the words I
quoted from Stroustrup's D&E:
"A notable exception to this agreement was Doug McIlroy, who stated
that the availabilty of exception handling would make systems less
reliable because library writers and other programmers will throw
exceptions rather than try to understand and handle problems."
In referring to this, I had in mind a good number of new programs I
have seen which behave in the way complained of because the authors
were in the habit of throwing exceptions at the first sign of trouble
without thinking through the consequences. Such programs are, as
people have pointed out, incorrect, but the question is whether the
presence of exception handling makes incorrect programs more likely. I
tend to think that it does, but that may well just be due to my
personal prejudice against the use of exceptions, and because I have
not had the good fortune to see exception handling used well.
A question for proponents of the extensive use of exceptions - what
would you recommend as a publicly available sample of exception
handling used well?
Peter Dimov
> >Note the assertion that exception-safe code must catch those
> >exceptions, which is plainly false. Exception-safe code rarely catches
> >anything. Having an exception specification available doesn't
> >magically make you proficient in writing exception-safe code.
>
> Exception specifications are part of the contract between user and
> implementor (as a user I want to know the full contract).
The exception specification (the list of exception types possibly
thrown by the function, or rather, their base classes), is a small
part of the contract. Requirements, the return value, effects,
exception safety guarantee, postconditions are typically more
important. As a user, you can't infer the full contract from the
function declaration, and you should never attempt to do that. You
must read the documentation.
John Potter
<non-ex...@iobox.com> wrote:
> BTW, did the original vector have at()?
The Oct 31, 1995 S&L paper did not have at.
John
James Kanze
news:<3DB1AAE3...@iobox.com>...
> James Kanze wrote:
> > > One robust example using exceptions is the STL.
> > Actually, the STL is more an example of a library which avoids
> > exceptions.
> At least length_error and out_of_range come to mind :)
> > About the only possible exception in the original STL was bad_alloc,
> > and that isn't generated by STL directly (and probably wasn't
> > present in the original STL either, since the original STL dates
> > from an epoch when new returned a null pointer).
> BTW, did the original vector have at()?
I don't think so; I've definitly used implementations that didn't have
it. But then, I think that the original STL was developped before
support for exceptions was widespread.
I suspect (but I'm not going to verify it) that most of the other use of
exceptions is new as well. More importantly, exceptions are only used
for avoidable conditions; it is quite easy to write a program which
makes extensive use of the STL without risking a single exception other
than bad_alloc.
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> ka...@gabi-soft.de (James Kanze) wrote
> > So what else is new? That's exactly what Doug McIlroy wrote : that
> > a good number of programs will terminate after printing a cryptic
> > message about an unhandled exception.
> It would be unfair to Doug McIlroy to let this stand uncorrected,
> since it was I, not he, who made the statement referred to. The only
> knowledge I have about Mr McIlroy's views are contained in the words I
> quoted from Stroustrup's D&E:
> "A notable exception to this agreement was Doug McIlroy, who stated
> that the availabilty of exception handling would make systems less
> reliable because library writers and other programmers will throw
> exceptions rather than try to understand and handle problems."
> In referring to this, I had in mind a good number of new programs I
> have seen which behave in the way complained of because the authors
> were in the habit of throwing exceptions at the first sign of trouble
> without thinking through the consequences. Such programs are, as
> people have pointed out, incorrect, but the question is whether the
> presence of exception handling makes incorrect programs more likely.
I'm no real friend of exceptions, but I'm skeptical with regards to
this. They probably make it more easy to write incorrect programs (in
the sense that it takes less lines of code), if you've decided that you
want to write incorrect programs. But I doubt that the presence (or the
absence) of exceptions conditions the desire to want to write correct
programs, and while I think that exception safety may be an issue, I can
hardly see the actual throw as a problem at the implementation level.
If you don't want to handle an error condition correctly, the easiest
solution, exceptions or no, is just to ignore it. If you don't test for
the case, you don't have to report the error.
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Sean Kelly
> ka...@gabi-soft.de (James Kanze) wrote
> >
> > So what else is new? That's exactly what Doug McIlroy wrote : that
a
> > good number of programs will terminate after printing a cryptic
message
> > about an unhandled exception.
> >
>
> It would be unfair to Doug McIlroy to let this stand uncorrected,
> since it was I, not he, who made the statement referred to. The only
> knowledge I have about Mr McIlroy's views are contained in the words I
> quoted from Stroustrup's D&E:
>
> "A notable exception to this agreement was Doug McIlroy, who stated
> that the availabilty of exception handling would make systems less
> reliable because library writers and other programmers will throw
> exceptions rather than try to understand and handle problems."
>
>
> In referring to this, I had in mind a good number of new programs I
> have seen which behave in the way complained of because the authors
> were in the habit of throwing exceptions at the first sign of trouble
> without thinking through the consequences. Such programs are, as
> people have pointed out, incorrect, but the question is whether the
> presence of exception handling makes incorrect programs more likely. I
> tend to think that it does, but that may well just be due to my
> personal prejudice against the use of exceptions, and because I have
> not had the good fortune to see exception handling used well.
One notable failing of the current exception scheme is, as James said,
that a cryptic error message is often the only clue about program
failure for exceptions. It would be tremendous if some support for
stack tracing were included in the language -- this would aid both
well-written and poorly-written programs.
Sean
James Kanze
news:<721ff0b.02102...@posting.google.com>...
> One notable failing of the current exception scheme is, as James said,
> that a cryptic error message is often the only clue about program
> failure for exceptions. It would be tremendous if some support for
> stack tracing were included in the language -- this would aid both
> well-written and poorly-written programs.
QoI issue. Any reasonable implementation will have something of this
sort. Eventually. When they've got all of the other new features
working.
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Christophe Lephay
d6651fb6.02102...@posting.google.com...> QoI issue.
What is a QoI issue ?
Christophe Lephay
Herb Sutter
<christop...@wanadoo.fr> wrote:
>"James Kanze" <ka...@gabi-soft.de> a =E9crit dans le message de news:
>d6651fb6.02102...@posting.google.com...
>
>What is a QoI issue ?
A "quality of implementation" issue -- once an implementation conforms to
the standard, the next question is how far the implementation goes beyond
the minimum that the standard requires to give a nice overall experience for
the user, which are QoI issues rather than conformance issues.
Herb
---
Herb Sutter (www.gotw.ca)
Convener, ISO WG21 - Secretary, ANSI J16 (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
C++ community program manager, Microsoft (www.gotw.ca/microsoft)
Check out "THE C++ Seminar" - Oct 28-30, 2002 (www.thecppseminar.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
apm
> "James Kanze" <ka...@gabi-soft.de> a =E9crit dans le message de news:
> d6651fb6.02102...@posting.google.com...
> > ken...@pacbell.net (Sean Kelly) wrote in message
> > QoI issue.
>
> What is a QoI issue ?
Quality of Implementation.
Michiel Salters
> d6651fb6.02102...@posting.google.com...
>
> What is a QoI issue ?
Quality of Implementation. It generally refers to those aspects of
C++ that may differ among compiler implementations, and which affect
the real-world quality. It's a counterpart to standards conformance;
the standard dictates what must be implemented, QoI what ought to be
implemented.
In this particular case, std::exception is such an example. It is part
of the implementation. A compiler vendor can include stack backtrace
information in it, which would clearly improve the QoI.
HTH,
--
Michiel Salters
Christophe Lephay
206gru84cf8tv4b89...@4ax.com...
> On 23 Oct 2002 20:09:57 -0400, "Christophe Lephay"
> <christop...@wanadoo.fr> wrote:
> >"James Kanze" <ka...@gabi-soft.de> a =E9crit dans le message de news:
> >d6651fb6.02102...@posting.google.com...
> >> QoI issue.
> >
> >What is a QoI issue ?
>
> A "quality of implementation" issue
Thanx :)
Christophe Lephay
Andreas Harnack
> I think the biggest problem with exceptions is the non-obvious flow of
> control.
> This catches out even experts from time to time, but in my experience many
> (if not most) users of C++ simply don't notice the problem exists.
>
> Not that many C++ programmers seems to see any possible problems with code
> like:-
>
> int SomeClass::fred()
> {
> ++in_use;
> call_something();
> --in_use;
> }
That's right, but ther's an alternative. What about
class Lock
{
int &lock;
public:
Lock(int &l) : lock(l) { lock++; }
~Lock() { --lock; }
}
int SomeClass::fred()
{
Lock lock(in_use);
call_something();
}
or if you prefer:
class Lock
{
static int in_use = 0;
public:
Lock() { in_use++; }
~Lock { --in_use; }
};
As far as I know destructors are called even when an exception is being
unwind. Of course this requires a different way of thinking. Instead of
'openening a file' you 'create an open file handle'. However, I still think
that this is one of best ways ensuring a clean way of cleaning up.
Andreas
Robert Klemme
"Sergey P. Derevyago" schrieb:
> Nevertherless, a sloppy coder can write something like this
>
> void f()
> {
> try {
> f();
> g();
> h();
> }
> catch (...) {
> // Wow, g() has thrown!
> }
> }
>
> while the source of the exception is f() or h(). And it's the issue with long
> try blocks.
which - i'd say - is connected to the issue of long methods:
proper coding should avoid lengthy methods for various good
reasons thus reducing the chance of long try blocks occurring.
regards
robert