I don't understand this statement. Obviously, the program cannot preform correctly, but that may not matter. For example, if a web page caches content on disk for the future, but there is an error. It may not matter that the particular disk write failed without any additional logic. The error would just cause a slightly longer load time next time.
Only if the disk write completely failed, leaving no traces of a half-broken cache entry.
If you have a half-written cache entry and don't deal with that situation somehow, you end up serving the user broken content from the cache.
It usually behooves us to have our code react to write errors.
So I guess I'll pick you up in about 10^10^9 years and you tell me how it goes. That is of course assuming that your program does not load new functions from your hard disk at some point which would add more state to you program thus stretching the waiting time even longer.
The problem is not to compute S=10^(3 * 10^10). In fact, we have already computed it. The problem that you originally discussed was waiting (at most) S steps until we can be sure that the finite state-machine either stops or runs forever. I assumed 10^9 steps per second. Thus, the waiting time would be approx. 10^10^9 years.
Wikipedia has a nice discussion on the topic with a quote by Marvin Minsky [1]:
"Minsky warns us, however, that machines such as computers with e.g., a million small parts, each with two states, will have at least 2^1,000,000 possible states: 'This is a 1 followed by about three hundred thousand zeroes ... Even if such a machine were to operate at the frequencies of cosmic rays, the aeons of galactic evolution would be as nothing compared to the time of a journey through such a cycle'"
[1] https://en.wikipedia.org/wiki/Halting_problem#Common_pitfall...
By bits of state, I only mean the bits that the program is allowed to change. It doesn't necessarily include OS code or initialization code, as long as they are immutable while the program is running.
Finite state -> solved halting problem
> HTML and CSS both are fault tolerant. If something goes wrong in HTML, browsers either display the content of the element or try to fix minor issues like unclosed elements for you. CSS skips lines of code it can’t understand and merrily goes on its way to show the rest of it. JavaScript breaks on errors and tells you that something went wrong. It will not execute the rest of the script, but throws in the towel and tells you to get your house in order first.
HTML (or rather, processing thereof) being fault tolerant is a complete misfeature. It's the result of browser in the 1990's trying to out-do each other in handling broken web pages in order to look more functional. Broken HTML should be loudly rejected (at least in pages which declare strict conformance to a modern dialect).
CSS skipping stuff it doesn't understand is harmless because a declarative language for assigning style properties. It doesn't have permanent effects, like making a call to a server to update a database record.
A program in a general purpose language cannot reliably continue after an error (without logic to handle that situation). Later steps depend on the earlier ones having executed correctly in every detail.