On 18/09/2014 17:49, H. S. Teoh via Digitalmars-d wrote:
On Thu, Sep 18, 2014 at 05:05:31PM +0100, Bruno Medeiros via Digitalmars-d
wrote:
On 01/08/2014 05:12, Walter Bright wrote:
On 7/31/2014 2:21 PM, Sean Kelly wrote:
Thoughts?
If a process detects a logic error, then that process is in an
invalid state that is unanticipated and unknown to the developer. The
only correct solution is to halt that process, and all processes that
share memory with it.
Anything less is based on faith and hope. If it is medical, flight
control, or banking software, I submit that operating on faith and
hope is not acceptable.
If it's a dvr or game, who cares :-) My dvr crashes regularly needing
a power off reboot.
"If it's a game, who cares" -> Oh let's see... let's say I'm playing a
game, and then there's a bug (which happens often). What would I
prefer to happen:
* a small (or big) visual glitch, like pixels out of place, corrupted
textures, or 3D model of an object becoming deformed, or the physics
of some object behaving erratically, or some broken animation.
* the whole game crashes, and I lose all my progress?
[...]
What if the program has a bug that corrupts your save game file, but
because the program ignores these logic errors, it just bumbles onward
and destroys all your progress *without* you even knowing about it until
much later?
(I have actually experienced this firsthand, btw. I found it *far* more
frustrating than losing all my progress -- at least I can restore the
game to the last savepoint, and have confidence that it isn't
irreparably corrupted! I almost threw the computer out the window once
when after a game crash I restored the savefile, only to discover a few
hours later that due to a corruption in the savefile, it was impossible
to win the game after all. Logic errors should *never* have made it past
the point of detection.)
T
I never implied a program should try to recover or ignore *all* bugs
that an assertion triggers. Sometimes it is better to crash the whole
program straight away, yes. But sometimes ignoring the bug and keep
going (or throwing an exception) is perfectly fine, and far better than
the alternative (full program crash).
And since when you're working with assertion checks you know if they
relate to game logic (the equivalent to "business" model), or to
presentation (UI, 3D, graphics, sound, etc.), you could define if the
program tries to continue running or not.
Under Walter's idea, you'd always crash the program.
Even if I had to choose between an occasional savefile corruption that
would render a game impossible to win, and having my games crash every
time ANY bug happened, I would still prefer the former. Because of all
the games I played in my life (I'm 31 and I like gaming, so I've played
quite a few), I've encountered maybe 3 games where that happened, that I
can remember (*). But I've seen visual glitches in nearly all games I've
played, and in maybe 60-75% of them those glitches happened *often
enough* that it would render the game virtually unplayable.
BTW, the same doesn't apply just to games. Same thing for other desktop
applications: IDEs, browsers, etc.. For example, in an IDE a bug in a
parser might bring some visual or behavior glitch ing the current
editor, but the whole IDE doesn't need to crash because of that!
* If anyone is curious:
Elder Scrolls 2 - Daggerfall: one of the possible endings, the one I was
trying to go for, became impossible to achieve due to a main quest bug.
Fallout 2: an big side quest in a town became completely unresolvable.
Ultima VII- The Black Gate : with a certain magical spell you can sneak
into a cave by a point that was meant only for exit. The problem is that
the cave was only meant to be entered in a different place, and much
later in the storyline. As such, in the cave you start to find
dialogues, and notes that are clues to a *murder* that hadn't even
happened yet! Unfortunately I only realized I was not meant to be the
cave after several hours of gameplay (battling high level monsters took
a while)... and even after that, I not only lost those hours, but I had
a big twist and a massive chunk of the game's storyline spoiled...
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
