5 ms·

It is significantly better than undefined behaviour, as it results in a noisy failure rather than silently incorrect results. Compile-time failures are best, s

• catnaroek 10y ago
  > It is significantly better than undefined behaviour, as it results in a noisy failure rather than silently incorrect results. This might be true in a deterministic setting, since the likelihood that a test suite will find the error is very high. But in a non-deterministic concurrent setting, throwing an exception that might be only caught once in a blue moon is just as bad as not doing anything about errors.
  • dikaiosune 10y ago
    Corrupting data with no warning or visible signs is far, far worse than crashing the application.
    • catnaroek 10y ago
      Data corruption is possible even in memory-safe languages, anyway. For instance, invariants of data structures might be violated. If you're really serious about data integrity, ask yourself - does any language even attempt to describe data structures stored on disk?
  • lmm 10y ago
    An occasional exception and silent corruption the rest of the time is still a lot better than silent corruption all the time - it's much easier to notice in the first place, and as long as you have one instance of the exception you have a stack trace to start from. And in practice the JVM/standard library throws ConcurrentModificationExecption pretty reliably.
    • catnaroek 10y ago
      > An occasional exception and silent corruption the rest of the time is still a lot better than silent corruption all the time The fundamental problem still remains, that in neither case can I use the language's semantics to guide the design of my program. > and as long as you have one instance of the exception you have a stack trace to start from Oh, really? How am I supposed to find what the problem is in the general case, from just a single exception stack trace that I might or might not get?
      • SamReidHughes 10y ago
        I think a stack trace and an exception would help most people with a modicum of debugging skills.
        • catnaroek 10y ago
          > I think a stack trace and an exception would help most people with a modicum of debugging skills. What if the error is difficult to reproduce in the first place? This isn't too uncommon in concurrent programming.
          • SamReidHughes 10y ago
            You can look at the code, see why you can't prove it correct, or work backward to see how the code could have gotten to such a state. Like I said, debugging skills.
            • catnaroek 10y ago
              > You can look at the code, Of course I can look at the code. Trust me the reason why I introduced the bug wasn't because I was looking at something else at the moment. > see why you can't prove it correct, Realistically, this is because the language and the program's design conspire to make proving anything about the program an uphill battle. If the language could perform basic sanity checks (e.g., no attempting to use objects after ownership has been transferred to someone else), then at least I could have a fighting change to manually prove more interesting properties. > or work backward to see how the code could have gotten to such a state. Doing this on a per case basis is an incredibly mind-numbing task.
• deleted 10y ago
  [deleted]