== Standard format Unix errors in Python programs

Here's some things on printing [[standard format Unix errors
../unix/StandardUnixErrorFormat]] in Python programs specifically,
based on things that I've both seen and done myself.

First, I tend to wind up putting standard _warn()_ and _die()_
functions into my programs, but they only handle very low level details
(putting the program name in and [[flushing things as necessary
../programming/HowToWriteToStderr]]). Beyond that:

* you should always catch _EnvironmentError_ instead of anything more
  specific. Functions are inconsistent about whether they raise _IOError_
  or _OSError_, so you shouldn't try to guess, just deal with the general
  case.
* don't try to do anything more complex with the EnvironmentError
  exception object than turning it into a string (with _str()_ or
  just by printing it as one). This will print the errno number as
  well as the text error message, but I don't consider this a bad
  thing.

* for things that cause the program to stop, if you handle each potentially
  failing statement with its own _try_/_except_ block you will rapidly
  go mad and repeat yourself a lot. Try to wrap as much as possible in a
  single generic block.  The ultimate version of this is to have a single
  _try_/_except_ in your main function and have the rest of your program
  ignore the issue.

  (This is not as applicable to warning messages, because you pretty
  much have to handle them fairly locally.)

  However, the more you aggregate exception handling, the more you
  need some way of keeping track of what the program was doing at the
  point where it blew up. I tend to solve this with what I call [[phase
  tracking PhaseTracking]].

In general, you have a design decision to make about how to handle fatal
errors. One way to handle them is to call _die()_ immediately where you
hit the error; another way is to let the exception bubble up (either in
its original form or re-wrapped into an internal exception class). The
drawback of the former is what I covered in ImportableMain; the more
the low-level bits of your program wind up calling _sys.exit()_, the
less you can conveniently test them by themselves because a failure
immediately shuts down everything. The drawback of the latter is that
you are forced into some sort of [[phase tracking PhaseTracking]] system.

=== Sidebar: my versions of _warn()_ and _die()_

Generally my versions of these functions look like this:

 import sys

 def warn(msg):
   sys.stdout.flush()
   sys.stderr.write("%s: %s\n" % \
                    (sys.argv[0], msg))
   sys.stderr.flush()

 def die(msg):
   warn(msg)
   sys.exit(1)

(See [[here ../programming/HowToWriteToStderr]] for why I put in the
calls to _.flush()_.)

More complicated games are possible with the name of the program (so
that it gets shortened by taking out the full path), but usually I don't
bother.