4 ms·

I haven't said that the JVM would be corrupt by NPE. But C program state would also not be, and you could do the same handling as in Java. But if your code inv

I haven't said that the JVM would be corrupt by NPE. But C program state would also not be, and you could do the same handling as in Java. But if your code invoked an NPE or bounds check, then it means either the algorithm is incorrect or the data it processes are already corrupt by incorrect processing earlier. Continuing in such situation increases the risk, because you don't have any guarantees which parts of the application state might have been already corrupted by the bug. I've seen many many times an NPE was a result of a shared data corruption caused by a data race. JVM does not guarantee thread state isolation, so one bug can break the state of all threads. > Log it and handle another request That gives you only a false sense of safety. A Java app (and any other app) may die for many other reasons you can't handle. You need to be prepared for that anyway if you want a reliable service. But if you are prepared for that, and your server can restart in 0.1 second, you don't win anything by recovering from NPEs.

kaba0 4y ago
Well, then consider deterministic failing a plus, as your C program may just continue along silently, with corrupted application state, and you might never learn of the problem (you are not likely to meet truly nullptr null pointers, they are just likely uninitialized, where all bets are off whether they are valid addresses) Being able to handle it correctly is just an additional benefit.
- pkolaczk 4y ago
  Ok, but now you're speaking about a different thing - memory safety. And that is an obvious advantage of Java over C. But C is a very low bar to compare to. There are dozens of other languages which are memory safe and some of them offer stronger guarantees than Java. Your Java program may continue along silently, with corrupted application state, because it invoked a race condition, and you might never learn of the problem.
  - kaba0 4y ago
    But even race conditions are well-defined in Java: you can’t get so called out-of-thin-air values. Some updates may not be visible from another thread, and of course dead/live locks are on the table (but they are everywhere, even the actor model doesn’t solve those).
    - pkolaczk 4y ago
      > you can’t get so called out-of-thin-air values You can't get out-of-thin-air primitive values (no word tearing). But you can still observe states that cannot be explained by any possible sequential interleaving of your program. E.g. your program can do: a = 0; b = 0; a = 1; b = 1; and another thread that does: print(b) print(a) may observe 4 different combinations of values, surprisingly including also this one: { a = 0, b = 1 } Why a corruption at a structure level should be considered less serious than tearing at a word level?
      - mcculley 4y ago
        The possibility of these very rare events does not change my mind about best practice for many kinds of deployed applications. I have production apps running right now using this pattern. The users would not be served better by stopping the whole app. We do capture the logs and fix the bugs encountered.

kaba0 4y ago

Well, then consider deterministic failing a plus, as your C program may just continue along silently, with corrupted application state, and you might never learn of the problem (you are not likely to meet truly nullptr null pointers, they are just likely uninitialized, where all bets are off whether they are valid addresses) Being able to handle it correctly is just an additional benefit.

pkolaczk 4y ago
Ok, but now you're speaking about a different thing - memory safety. And that is an obvious advantage of Java over C. But C is a very low bar to compare to. There are dozens of other languages which are memory safe and some of them offer stronger guarantees than Java. Your Java program may continue along silently, with corrupted application state, because it invoked a race condition, and you might never learn of the problem.
- kaba0 4y ago
  But even race conditions are well-defined in Java: you can’t get so called out-of-thin-air values. Some updates may not be visible from another thread, and of course dead/live locks are on the table (but they are everywhere, even the actor model doesn’t solve those).
  - pkolaczk 4y ago
    > you can’t get so called out-of-thin-air values You can't get out-of-thin-air primitive values (no word tearing). But you can still observe states that cannot be explained by any possible sequential interleaving of your program. E.g. your program can do: a = 0; b = 0; a = 1; b = 1; and another thread that does: print(b) print(a) may observe 4 different combinations of values, surprisingly including also this one: { a = 0, b = 1 } Why a corruption at a structure level should be considered less serious than tearing at a word level?
    - mcculley 4y ago
      The possibility of these very rare events does not change my mind about best practice for many kinds of deployed applications. I have production apps running right now using this pattern. The users would not be served better by stopping the whole app. We do capture the logs and fix the bugs encountered.