Wow. I suggest your read this paper: https://www.usenix.org/conference/osdi14/technical-sessions/presentation/yuan Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems, Ding Yuan et al
Unhandled errors lead to catastrophic failures of distributed systems, when proper handling would have prevent these crashes. While this research examines only distributed systems like HDFS and Cassandra, I believe the same line of reasoning applies to non-distributed apps as well. Really, why crash when you fail to open a file or obtain a lock? Rik On Tue, Dec 30, 2014 at 6:50 AM, Scott Guthery <s...@acw.com> wrote: >> What questions would you (plural) ask? > > > 1) Is "error-handling code" an oxymoron? > > By which I mean isn't the existence of a state the programmer didn't expect > (the "error") an implicitly-admitted programmer (not program) error? In > other words, by even countenancing the notion of error-handling code aren't > we giving the programmer a pass on shoddy work? Shouldn't we declare that > the notion of error-handling code is "considered harmful" to use Knuth's > phrase? > > 2) How often is the error-handling under consideration code executed? > > Is it possible that the "error" condition that the code has been added to > the system to handle will never hold so that the code is in effect dead > code? If the programmer knows the condition can arise then it's not an > error state but can be handled as a defined state. If the programmer > doesn't know whether or not the condition can arise, shouldn't they > determine which is the case before larding more code into the system? > Shouldn't the existence of even one undefined state in a system give us > pause? > > 3) What assertions can be made about flow of control in a system that > includes error-handling code? > > Doesn't the existence of error-handling code mean that the system can in a > sense go out of control where by 'control' I mean a designed execution path? > Does system test ensure the execution of all error-handling code? Are all > combinations of error-handling execution paths covered? When does > error-handling code simply pass the "error" onto some other code body? > > There have been some studies of exception handling and some of them found > systems that spent most of their time in this state. (The mind boggles when > one thinks of the number of exceptions thrown each day ACA connectors.) > > Note that I am not writing about programming constructs such a long jump and > try/catch. Such constructs in and of themselves can create well-defined > flow of control. But most of the time their semantics are "I don't know > what's going on so I'm outta here." At which point I suggest that the > programmer be dismissed. > > Cheers, Scott > > > _______________________________________________ > langsec-discuss mailing list > langsec-discuss@mail.langsec.org > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss _______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
