Scanning a file

[Alex Martelli]

Steven D'Aprano <steve at REMOVETHIScyber.com.au> 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