Re: Boost scoped_ptr design question
"James Kanze" <james.kanze@gmail.com>
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).
Crashing games are annoying. But games that mess up the save files are even
more so. And "recovery" so often lead to saves that stopped working a few
hours later, making you lose dozens of hours -- or just lead to uninstall
and blacklisting the company.
Certainly depends on "situation", in a game there can be many situatuions
that are not coming from undefined behacior or messed up state, just not
thinking some interaction of events. Where recovery is possible at cost of
losing some pixels on the screen. IMO those are not matching the original
line of logic errors we discussed.
(OTOH I see that game programmers reaching 2010 are still fighting trivial
issues like memory leaks. And management that dumps pre-beta stage into
release. See 'Elemental war of magic' for a recent example. :-((( )
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.
My estimate for no-mutabe-state software is pretty low.