On Sunday, 19 January 2014 at 08:41:23 UTC, Timon Gehr wrote:
This is not a plausible assumption. What you tend to know is that the program is unlikely to fail because otherwise it would not have been shipped, being safety critical.
I feel that this "safety critical" argument is ONE BIG RED HERRING.
It is completely irrelevant to the topic which is whether it is useful to have recovery mechanisms for null-pointers or not. It is, but not if you are forced to use them. Nobody suggests that you should be forced to recover from a null dereference?
Nevertheless: If your application is safety critical and not proven correct or have not undergone exhaustive testing (all combinations of input) then it most likely is a complex system which is likely to contain bugs. You can deal with this by partitioning the system into independent subsystems (think functional programming) which you in a domain specific manner control (e.g. you can have multiple algorithms and select the median value or the most conservative estimate, spinning down subsystems reverting to a less optimal state (more resource demanding), running a verifier on the result etc etc.
I.e. when it fails, you don't know that it is unlikely to be caused by something. It could be hardware failure, and even a formal correctness proof does not help with that.
But hardware failure is not a valid issue when discussing programming language constructs?
Of course the system design should account for hardware failure, extreme weather that makes sensors go out of range and a drunken sailor pressing all buttons at once.
Not a programming language construct topic.
Irrelevant. He is arguing for stopping the system once it has _become clear_ that the _current execution_ might not deliver the expected results.
Then you have to DEFINE what you mean by expected results. Which is domain specific, not a programming language construct issue in a general programming language.
If the expected result is defined be: having a result is better than no result, then stopping the system is the worst thing you could do.
If the expected result controls N different systems then it might be better to fry 1 system and keep N-1 systems running than to fry N systems. That's a domain specific choice the system designer should have the right to make. Sacrifice one leg to save the other limbs.
Think about the effect of this: 1 router detects a bug, by the logic in this thread it should then notify all routers running the same software and tell them to shut down immediately. Result: insta-death to entire Internet.
