> You can't crash. That's the exact point of runtime assertions. You can't crash, so you fail exactly at the moment something is corrupted. One of the reasons

> You can't crash. That's the exact point of runtime assertions. You can't crash, so you fail exactly at the moment something is corrupted. One of the reasons Go didn't devided to include runtime assertions (and one of the only choises for Go I really dislike) is that they aren't exactly safe because you still have to deal with that failure, and I suppose it's very easy to fuck it up. What you're describing in your post is essentially what I think of when I say runtime assertion. You use them to revert to the previous valid state and retry, you can micro-reboot, you can go into a "factory setting" where your software can continue until an engineer can actually work on it. Things like that. The primary difference is that with runtime assertions, you stop exactly when the corrupted states occours instead of trying to continue with that corrupted state. It's not like this should replace testing or any of the other things you bring up. I still strongly recommend testing. Tests are for prevention of errors, however, and runtime assertions are for dealing with errors when they happen at runtime. Exception handling is the other way around it, but with exceptions you continue with the corrupted state and try to deal with it down the line. I don't personally like that. > Never fails isn't possible. In the previous decade we've had 0 software failures causing shutdown of equipment in any of our many solar parks. This is not to say we haven't had failures. Last I checked the data we've had around 700. incidents which required human intervention, but in every case, the software was capable of running at "factory settings" until the component could safely be repaired or replaced. By contrast we've had quite a lot of hardware failures. Now... it's not exactly life threatening if parts of a solar plant fails, at least not on most plants. In almost any case it'll only cost money, and the reason we're so tight on not failing is actually exactly that. The contracts around downtime responsibility are extremely rigid and my organisation cares quite a lot about placing that responsibility outside of "us". So somewhat ironically we're doing software "right" in this one place because of money, and not because it's the right thing to do. But hey, the work is fun. > Clean/clear/simple code. I would replace "Clean" in this part, but it depends on what you mean. YAGNI > Uncle Bob!