[kubanczyk]

That's subtly different. It's secondary whose fault is this, what primarily matters is whether you should continue with the rest of the process.

There is always a cleanup layer, the trick is to choose well between 1 and 2:

  1. Some code in the same OS process is able to bring data back to order.

  2. OS can kill the process and thus kill any corruption that was in its address space.

  3. Hardware on/off button can kill the entire RAM content and thus kill any corruption that spilled over it.

Take for example an unexpected divide by zero, that's a classic invariant violation. The entire process should blow up right there because:

- it knows that the data in memory is currently corrupted,

- it has no code to gently handle the corruption,

- and it knows the worst scenario that can happen: some "graceful stop", etc., routine might decide to save the corrupted data to disk/database/third-party. Unrecoverable panic (uncatchable exception) is a very good generic idea, because persistently-corrupted-data bug is a hundred times worse than any died-with-ugly-message bug as far as users are concerned.

[tcfhgj]

> Take for example an unexpected divide by zero, that's a classic invariant violation. The entire process should blow up right there because:

> - it knows that the data in memory is currently corrupted,

> - it has no code to gently handle the corruption,

are these conditions or implications?

- corruption isn't necessary: it could be the consequence of a bug

- corruption can be handled sometimes: fetch the data from the source again, apply data correction algorithms

- you know and control what the graceful stop does; maybe not save the corrupted data to disk? or maybe save it to disk and ask the user to send it to you

[kubanczyk]

I took several assumptions to build an argument why some errors should result in process-level termination.

By "corruption" I mean much more than merely a hardware bit error. I mean any situation when data no longer has a meaning for a user.

By "unexpected" I mean that the program has not been prepared to deal with the situation: there is no code there to "fetch the data from the source again", etc.

> you know and control what the graceful stop does

No, in fact I'm exploring here situations when I don't know this with certainty.