On 10/01/10 00:24, TheFlyingDutchman wrote: > >> >>> If I had to choose between "blow up" or "invalid answer" I would pick >>> "invalid answer". >> >> there are some application domains where neither option would be >> viewed as a satisfactory error handling strategy. Fly-by-wire, petro- >> chemicals, nuclear power generation. Hell you'd expect better than >> this from your phone! >> > > I wasn't speaking generally, just in the case of which of only two > choices RG's code should be referred to - "blowing up" or "giving an > invalid answer".
I can make any application never blows up. Just put this in the main() of every application you write: while True: try: ... program goes here ... except: pass Done. Program never halted execution, it never blows up. My program is bug free, heck why do thousands of computer scientists can't figure out that such a simple construct will fix all bugs once and for all? > I think error handling in personal computer and website software has > improved over the years but there is still some room for improvement > as you will still get error messages that don't tell you something you > can relay to tech support more than that an error occurred or that > some operation can't be performed. I think the ideal error message tells the user exactly what's wrong and how to fix the problem. A generic error message like "This program encountered a problem, and need to close." is as useless as an error message could be. > But I worked with programmers doing in-house software who were > incredibly turned off by exception handling in C++. I thought that > meant that they preferred to return and check error codes from > functions as they had done in C, and for some of them it did seem to > mean that. Introduce them to RAII (Resource Acquisition Is Initialization), that's a superior alternative to exception handling in C++. > But for others it seemed that they didn't want to > anticipate errors at all ("that file is always gonna be there!"). I > read a Java book by Deitel and Deitel and they pointed out what might > have lead to that attitude - the homework and test solutions in > college usually didn't require much if any error handling - the > student could assume files were present, data was all there and in the > format expected, user input was valid and complete, etc. Personally, the amount of error message I'd design into the program depends on the expected level of proficiency of the expected users. If I'm developing for an in-house software, and most of the users of my program are expected to be experts or have necessary training, I'd be less inclined to include sophisticated error checking in favor of simplicity (but I usually work in high-level language, where errors like non-existent file will throw an exception instead of passing silently, so take it with a grain of salt). If I'm designing software for a general public though, I'd include multitudes of idiot checking. -- http://mail.python.org/mailman/listinfo/python-list