Steven D'Aprano <[EMAIL PROTECTED]> wrote: ... > > Don't ever catch and ``handle'' exceptions in such ways. In particular, > > each time you're thinking of writing a bare 'except:' clause, think > > again, and you'll most likely find a much better approach. > > What would you -- or anyone else -- recommend as a better approach?
That depends on your application, and what you're trying to accomplish at this point. > Is there a canonical list somewhere that states every possible exception > from a file open or close? No. But if you get a totally unexpected exception, something that shows the world has gone crazy and most likely any further action you perform would run the risk of damaging the user's persistent data since the macchine appears to be careening wildly out of control... WHY would you want to perform any further action? Crashing and burning (ideally leaving as detailed a core-dump as feasible for later post-mortem) appears to be preferable. (Detailed information for post-mortem purposes is best dumped in a sys.excepthook handler, since wild unexpected exceptions may occur anywhere and it's impractical to pepper your application code with bare except clauses for such purposes). Obviously, if your program is so life-crucial that it cannot be missing for a long period of time, you will have separately set up a "hot spare" system, ready to take over at the behest of a separate monitor program as soon as your program develops problems of such magnitude (a "heartbeat" system helps with monitoring). You do need redundant hardware for that, since the root cause of unexpected problems may well be in a hardware fault -- the disk has crashed, a memory chip just melted, the CPU's on strike, locusts...! Not stuff any program can do much about in the short term, except by switching to a different machine. Alex -- http://mail.python.org/mailman/listinfo/python-list
