Re: We do not use C++ exceptions
On Jan 29, 9:53 am, Thant Tessman <thant.tess...@gmail.com> wrote:
Peter Dimov wrote:
[...] For our purposes we can
think of "undefined behavior" as "your program stops dead". [...]
The problem with "undefined behavior" is that the above is not at all
what it means. "Undefined behavior" means exactly that: undefined
behavior. It means your program might merely produce erroneous results
which you may or may not discover before someone relies on those results.
This is the technical meaning of the term, but the "undefined
behavior" design philosophy is different. It means that there do exist
programs that are formally "incorrect". Technically, when a program is
determined to be incorrect, its behavior is outside the realm of the
language and library guarantees. Ideally, when a program is determined
to be incorrect, it ought to be stopped dead without being given the
opportunity to inflict any further damage. This is what assert does,
and this is why people who follow the "UB" library design philosophy
prefer asserts for contract violations instead of a well-defined
response (be it an error code or an exception, both of which return
control to the program, which has already been determined to be
incorrect.)
Avoiding "UB" at the language and library level makes all programs
_formally_ correct, although it of course does not and cannot make
them _actually_ correct.
"UB" is in quotes here because it is possible to have a language whose
behavior is completely defined but which adheres to the "UB"
philosophy. (Why this is not practical for C++ should be obvious, but
it is possible.) Returning control to the program is not the only way
to define behavior on contract violations, yet this is mostly what is
meant when one says that UB is something to avoid.
Throwing an exception when a program overflows or underflows or attempts
to index beyond the end of an array is not always necessarily about
catching it and "continuing happily." And it's not about shifting the
bug burden. It's about making sure a program never exhibits "undefined
behavior."
The correct use of returning control to the program on contract
violations is when one absolutely has to attempt recovery and continue
(well, maybe not happily). Two examples are a program that has
physical side effects or a multithreaded server. I prefer independent
processes for both, but one doesn't always have the choice.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]