3 ms·

It entirely depends on the application's role. If it's used in a video game with no save slots, where a crash is just going to lose lots of progress, I'd rathe

by byuu 12y ago

It entirely depends on the application's role. If it's used in a video game with no save slots, where a crash is just going to lose lots of progress, I'd rather attempt to keep going even if there's an error, but only in release builds. Crash in debug builds to try and alert the programmer. If it's used to save important work, where the bad divide could lead to data corruption, it's probably better to crash than risk the corruption. Although if you have the capability to ask the user what to do, that would be ideal. If it's to develop something that handles money or lives, or is eg deployed on a satellite, not even crashing is acceptable. In that case, I'd force the language to have the user test with something like Haskell's "Maybe". For instance: if(result = x / y) { //x / y returns an object: maybe<int> z = result.get() } // } else { handle division by zero case } (edit: of course even that isn't fool-proof if the user tries hard enough to work around your safeguards. But you can't blame the language if the user is actively thwarting it.)

ridiculous_fish 12y ago
There's two competing software philosophies which are sometimes called "banker" and "moon rover." If you are writing a bank program, you want to catch errors immediately, to ensure that mistakes can't silently propagate. But if you are writing a moon rover, under no circumstances abort: keep going no matter what! We have two Mars rovers right now, Opportunity and Curiosity. Fittingly, these use PowerPC chips, which are in the moon rover camp: divide-by-zero is zero. Really! Go get a PowerPC Mac, do a divide-by-zero, and you just silently get zero. Solution #1 baked into the ISA. Not many people seem to have noticed, so it can't have caused too much trouble. (Apologies for reposting my reddit comment here)
- byuu 12y ago
  Yep, this is also the case with some gaming systems; eg the SNES CPU's ALU, and also its Sony APU (SPC700). Division by zero continues on instead of crashing. They usually return 0 for the quotient, and ~0 ("-1") for the remainder. So if it's not too much work, I'd like my language to give me the option based on the type of application I want. But if it were forced to be a choice, I'd probably err on the side of safety.
thegeomaster 12y ago
I was writing games in C++ for a long, long time, and recently started working on a very different project—a server using libuv and a lot of crypto operations with OpenSSL. I defined an ASSERT macro, and not thinking about it, wrote it so that in release builds, ASSERT does nothing. It's a very common thing to do in game engines: you do assertions on all sorts of things to catch user errors, but they slow the engine down a lot, and you don't want to crash the whole game because of some (maybe innocuous) error so you just ignore failed assertions. Imagine my surprise when I did a release build for the first time and realized what I'd done :)
- mhlakhani 12y ago
  Could you elaborate a little on what happened? What exactly went wrong?
  - thegeomaster 12y ago
    Well, this was a server, and it was also multithreaded, so many synchronization bugs that didn't happen in debug builds did happen in release ones because of timing. Without assertions, though, none of these was caught on time, so I was left with mystical crashes, garbage data sent out to clients, etc etc. I spent hours and hours in valgrind and gdb, and only then realized that none of the assertions worked. When I re-enabled them, I was able to snipe (almost) all of the bugs easily. But this is generally the kind of thing that happens when you turn a blind eye to errors somewhere where that's not a good way to go. In gamedev, sure, nobody cares, but if you're dealing with crypto and security-sensitive stuff, well, what I did was very, very bad. It's a small proof-of-concept pet project, but if I was ever to release something like that to the public, it would be very irresponsible of me.
    - jl6 12y ago
      With total respect to what you're saying, I'd just like to say that I care about games and other non-mission-critical software. I am continually disappointed by buggy glitchy unreliable applications which have clearly been rushed out to meet a release window. It's as if we've all been trained to accept poor quality, based on the excuse that "it's not handling payments or running a nuclear reactor so it's OK to be sloppy".

by byuu 12y ago

ridiculous_fish 12y ago

There's two competing software philosophies which are sometimes called "banker" and "moon rover." If you are writing a bank program, you want to catch errors immediately, to ensure that mistakes can't silently propagate. But if you are writing a moon rover, under no circumstances abort: keep going no matter what! We have two Mars rovers right now, Opportunity and Curiosity. Fittingly, these use PowerPC chips, which are in the moon rover camp: divide-by-zero is zero. Really! Go get a PowerPC Mac, do a divide-by-zero, and you just silently get zero. Solution #1 baked into the ISA. Not many people seem to have noticed, so it can't have caused too much trouble. (Apologies for reposting my reddit comment here)

byuu 12y ago
Yep, this is also the case with some gaming systems; eg the SNES CPU's ALU, and also its Sony APU (SPC700). Division by zero continues on instead of crashing. They usually return 0 for the quotient, and ~0 ("-1") for the remainder. So if it's not too much work, I'd like my language to give me the option based on the type of application I want. But if it were forced to be a choice, I'd probably err on the side of safety.

thegeomaster 12y ago

I was writing games in C++ for a long, long time, and recently started working on a very different project—a server using libuv and a lot of crypto operations with OpenSSL. I defined an ASSERT macro, and not thinking about it, wrote it so that in release builds, ASSERT does nothing. It's a very common thing to do in game engines: you do assertions on all sorts of things to catch user errors, but they slow the engine down a lot, and you don't want to crash the whole game because of some (maybe innocuous) error so you just ignore failed assertions. Imagine my surprise when I did a release build for the first time and realized what I'd done :)

mhlakhani 12y ago
Could you elaborate a little on what happened? What exactly went wrong?
- thegeomaster 12y ago
  Well, this was a server, and it was also multithreaded, so many synchronization bugs that didn't happen in debug builds did happen in release ones because of timing. Without assertions, though, none of these was caught on time, so I was left with mystical crashes, garbage data sent out to clients, etc etc. I spent hours and hours in valgrind and gdb, and only then realized that none of the assertions worked. When I re-enabled them, I was able to snipe (almost) all of the bugs easily. But this is generally the kind of thing that happens when you turn a blind eye to errors somewhere where that's not a good way to go. In gamedev, sure, nobody cares, but if you're dealing with crypto and security-sensitive stuff, well, what I did was very, very bad. It's a small proof-of-concept pet project, but if I was ever to release something like that to the public, it would be very irresponsible of me.
  - jl6 12y ago
    With total respect to what you're saying, I'd just like to say that I care about games and other non-mission-critical software. I am continually disappointed by buggy glitchy unreliable applications which have clearly been rushed out to meet a release window. It's as if we've all been trained to accept poor quality, based on the excuse that "it's not handling payments or running a nuclear reactor so it's OK to be sloppy".