[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.