4 ms·
I didn't mean "just" in that sense, I mean "just" as in "solely dedicated to". Most apps have error handling code taking up what? 20-30% of the code at the mos
by rurounijones 14y ago
I didn't mean "just" in that sense, I mean "just" as in "solely dedicated to".
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)
- Swannie 14y ago20 - 30? What are you writing?! I work mostly on integration code. I'd say I see more like 60% code to handle errors, exceptions, etc.
- loeg 14y ago> 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. 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 :-).