4 ms·

> 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 re

> 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.
lmm 10y ago
The stack trace tells you where one of the concurrent accesses happened. As opposed to data corruption where (if you even manage to witness it in the first place) all you know is that one of the things that accesses that memory got it wrong.

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.

lmm 10y ago

The stack trace tells you where one of the concurrent accesses happened. As opposed to data corruption where (if you even manage to witness it in the first place) all you know is that one of the things that accesses that memory got it wrong.