Re: Boost scoped_ptr design question
On Dec 15, 8:40 pm, "Marc" <xmarc...@spot.net> wrote:
James Kanze wrote:
On Dec 15, 12:55 am, "Marc" <xmarc...@spot.net> wrote:
Why do the operations of scoped_ptr use undefined behavior instead of
throwing?
scoped_ptr is designed to emulate a pointer; raw pointers have
undefined behavior, so so does scoped_ptr. (One can argue
whether this is a good thing or not, but nothing in undefined
behavior prevents an implementation from doing the right thing,
e.g. inserting an assert.)
Throwing an exception is, of course, the wrong thing. If you
discover a programming error, you should abort (in most
applications, anyway---there are exceptions).
"most applications"? Can you qualify that?
Not really. "Most" is "most", a relatively vague word
(intentionally). Concretely, I don't know how to count
"applications", so I can't provide anything more precise. But
globally, the cases where not aborting is appropriate seem to be
exceptions to the general rule, and very much in a minority.
When you say "most" without
qualifying it, then the referrent set of applications is ALL
applications, from the one in that nifty Star Trek watch to the GUI on
your desktop (not that I am suggesting that those 2 examples really
define endpoints).
Games are definitely an exception to the rule, and game software
should probably throw (and catch at a higher level, and try to
recover). If the coding error has not caused damage, or the
damage was very local, the player may not even notice the
glitch, and otherwise, the game experience is the same as if
you'd aborted. The same thing probably holds for software which
is only "browsing"; which doesn't modify data (has no files open
for writing, other than logs or temp files, etc.). As soon as
the software modifies persistent data, or has some sort of
"behavior", you have to weigh the possible harm continuing might
do; in such cases, it's almost never appropriate to do anything
else but abort. And of course, in any critical application,
there will be some sort of redundancy or backup, and the rule is
to terminate the software as quickly as possible, executing as
little additional code as possible.
--
James Kanze