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