I remember reading that they cannot use exceptions and have to handle every possible scenario. Part of me wonders how much of the source code is just error handling.
SpaceX's programming rules are probably very similar to those used at NASA JPL: http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
This article is often referenced for NASA's software practices, although it's now almost 20 years old: http://www.fastcompany.com/28121/they-write-right-stuff
Is there anything more comprehensive and current than that?
Most apps have error handling code taking up what? 20-30% of the code at the most? For some reason I imagine this stuff being almost 70% error handling but I am not sure if that is realistic.
So, assuming there are shed loads of error handling that knocks on to everything else about the system. How do they test it? How do they spec out all the possible conditions? What do they do differently to someone writing a SaaS, Desktop app or IOS app?
It looks like it would be a very different world which is not really written about (Apart from the old articles posted in one of the above comments)
I work mostly on integration code. I'd say I see more like 60% code to handle errors, exceptions, etc.
I work in a FreeBSD-derived kernel in areas related to the buf / caching subsystem, which probably has a lot of similarities to pre-2.6 linux (they have diverged more since the 90s). I don't know that I can quantify it, but 20-30% feels like a low number.
> So, assuming there are shed loads of error handling that knocks on to everything else about the system. How do they test it?
One thing we use to test error-case handling is "fail points" — sysctls usable from unit tests that trigger some fault condition. These aren't perfect — they are manually added to code, and because of this, coverage is fairly low — but they're a start.
> How do they spec out all the possible conditions? What do they do differently to someone writing a SaaS, Desktop app or IOS app?
Good questions :-).