I don't understand how "error-handling" code could be considered an oxymoron. Error handling code exists to deal with error state that the programmer specifically anticipated. The contradiction would be for the programmer to write code for the state that they did not anticipate, how could they write such code?
For example, consider java.io.File.createNewFile, which can throw an exception for many reasons, including: - the JVM SRM denies the operation - there is an I/O error I/O errors could have many causes. The programmer doesn't know exactly which error there will be, but the API and language forces the programmer to consider that when invoking createNewFile something might go wrong at runtime, and then something else should happen. Usually log and exit, though deciding specifically how to handle an error is usually an order of magnitude more difficult than identifying where errors could start, I think. On 12/30/2014 08:50 AM, Scott Guthery 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
