Indeed you don't.
Division can't "fail"; rather it has inputs for which it's not defined, and for which attempting to perform it is a programming error.
-
-
Replying to @RichFelker @jackmott42
What about other kind of resources exhaustion (fds? inodes?), or simply reported hardware failure? What when (not if) the network goes down? You can't solve everything by static analyis; you need a plan for when something fails dynamically anyway.
1 reply 0 retweets 0 likes -
Replying to @laurentbercot @jackmott42
Well some of those are symptoms of an OS model that's not appropriate for deep safety-critical embedded (but might be with proper implementation and constraints on what's running on it)...
1 reply 0 retweets 0 likes -
Yes you need a plan for what happens when something fails, but "device got smashed in a collision" or "sensor failed from excess wear" are completely different classes of failure from "software is leaking memory and so we OOM'd".
1 reply 0 retweets 2 likes -
In a sense, on a tightly-controlled embedded system running a fixed known set of software, OOM is a "programming error" just like division-by-zero; the problem is that the point of the error (leak/excess usage) is not easily detectable...
2 replies 0 retweets 0 likes
...and languages don't provide means for static analysis proofs that it doesn't happen.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.