No, a hard error in this case is one that is triggered by a hardware interrupt and is not interruptible by the system. This is explained in the article.

It can be kind of hard to route an error that happens deep inside a kernel to an application.

Disk errors happening after a deferred write are a classic example that's still applicable today. Your process might have succeeded a write(2) into cache and exited cleanly, then when it's time to write to disk, something bad happens. There's no way to tell an application that is long gone.

But you would use unbuffered writes if you really cared. Otherwise there’s nothing actionable that can be done by the application unless there was some kind of signal or callback / APC.

All correct. You're making my same points.

I'm illustrating a real world scenario where such a mapping may not be possible.

Further, if the issue is a global problem, like filesystem corruption, it becomes even more ambiguous -- maybe that write could have worked or maybe it wouldn't, but the filesystem may just globally make everything read only and start failing writes.

So my point is that these errors were meant for catastrophic failures that don't map neatly into being handled with the process. In a modern kernel there are way fewer of these conditions than was acceptable in the early 90s. But there are a few similar things that are still common.

Fun fact, your question was 7% the length of the article which clearly answered your question.

What were the odds of that happening?:0