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.
- 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.
> - 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
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.
If a bug triggers an exception then with a strong compiler that is sufficiently advanced then these bugs can be found by the compiler.
Exceptions also require execution, but that does not suggest that they are encompassed by bugs. The lack of a third term tells that there is no overlap. If "bug" covered both exceptions and where human expectations are violated, there would necessarily be another term just for the case where human expectations are violated. But there is no such term...
...that I've ever heard. If it is that I've been living under a rock, do tell.
But then for example if there is no GPU at all on the system, it's neither a "programming error" nor something the user could really do something about, but it is exceptional, and requires us to stop and not continue.
That depends if it is due to the programmer making a mistake in the code or an environmental condition (e.g. failing hardware). The former is exceptional if detected, a bug if not detected (i.e. the program errantly carries on as if nothing happened, much the dismay of the user), while the latter is a regular error.
> But then for example if there is no GPU at all on the system, it's neither a "programming error" nor something the user could really do something about, but it is exceptional
Not having a GPU isn't exceptional in any sense of the word. It is very much an expected condition. Normally the programmer will probe the system to detect if there is one and if there isn't, fall back to some other option (e.g. CPU processing or, at very least, gracefully exiting with feedback on how to resolve).
The programmer failing to do that is exceptional, though. Exceptions are "runtime compiler errors". A theoretical compiler could detect that you forgot to check for the presence of a GPU before your program is ever run.
The grey area is malfunctioning CPU/memory. That isn't programmer error, but we also don't have a good way to think about it as a regular error either. This is what "bug" was originally intended to refer to, but that usage moved on long ago and there is seemingly no replacement.
For example:
1. You’d want to display a message that they need a GPU.
2. Call stack information isn’t helpful in diagnosing the issue.