I disagree. This code is just lucky enough to be able to detect the data corruption, but without very deep understanding afterward the whole system state has to be assumed to be corrupted. You can retry until the code doesn't detect data corruption, but you have to assume other state is also corrupted. The right thing would be to scream loudly at the user that their system is unstable and to expect (future) data corruption unless the hardware + firmware (or its configuration) is fixed.
Sure it's unpleasant to be the messenger of bad news, but the alternatives are far worse unless the system is just a dedicated game console without any background processes (which isn't how those CPUs are used).
Yeah, I had a RAM issue that might or might not have involved turning on XMP, with eventually as a result several RAM sticks with errors (BadRAM is amazing BTW, sadly, *nix-only), and worse, corrupted storage partitions !
Sure it's unpleasant to be the messenger of bad news, but the alternatives are far worse unless the system is just a dedicated game console without any background processes (which isn't how those CPUs are used).