← Back to context

Comment by meinersbur

9 months ago

My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.

10 comments

meinersbur

Reply
mrkeen  9 months ago

> My impression is that this is due to their non-robust programming style.

It's been 50+ years. I don't think that it's worthwhile just telling the programmer to do a better job.

> They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.

This is a pretty big feedback loop:

  * The programmer puts the null into the code
  * The code is released
  * The right conditions occur and the player triggers it
  * IF DONE SKILLFULLY AND CORRECTLY the game is able to recover from the null-dereference, write it out to a log, and get that log back to the developers.
  * The programmer takes the null out of the code.

If you don't do the first step, you don't get stuck doing the others either.

  • nurettin  9 months ago

    50+ years and people still fail to grasp this.

    You have to put something (an optional, or a default constructed object in a useless state) and all you did was to skip the null check. In case of optional, you introduced a stack rewind or a panic. Everything else stayed the same. Maybe that default even deleted the hard drive instead of crashing.

    Coding is hard. "just don't code" is not the answer. You can avoid something, that doesn't mean it won't show up in some other fashion.

    • sam0x17  9 months ago

      Again, if you disallow unwrapping and panicking at the CI level, you actually force your developers to properly handle these situations.

    • mrkeen  9 months ago

      > You have to put something (an optional, or a default constructed object in a useless state)

      No, you really don't. There is no default number, no default string, no default piece of legislation, no default function.

astrange  9 months ago

Arbitrary recovery to null pointers isn't a good way to do robust programming. I recommend doing the exact opposite actually.

https://en.wikipedia.org/wiki/Crash-only_software

https://medium.com/@vamsimokari/erlang-let-it-crash-philosop...

  • 0x457  9 months ago

    A crash of an actor in BEAM is incomparable to a crash of a video game.

    • epr  9 months ago

      Is it? Is there no reasonable case where you have a subsystem in a game crash, then restart itself? Unless I'm mistaken, I've experienced this myself in video games more than once. Anything beats a full crash with a pointless error message.

      1 reply →

    • astrange  9 months ago

      But if your video game uses a DSL for actors then you can do it in the DSL, which avoids special arbitrary bug-hiding behavior.