Which errors to catch when a module doesn't document all of its errors? (plistlib)
<p>TL;DR: What kind of errors to catch when a module doesn't document all of its errors?</p>

<p><strong>Scenario</strong>:</p>

<p>I'm trying to read a series of <a href="https://en.wikipedia.org/wiki/Property_list" rel="nofollow">property lists</a> using <a href="https://docs.python.org/2/library/plistlib.html" rel="nofollow"><code>plistlib</code></a>. I have no control over the files. If a file couldn't be read, I want to skip it.</p>

<p>My question is what kind of errors should I catch? </p>

<p><code>plistlib.readPlist</code> documents <code>IOError</code> and <code>xml.parsers.expat.ExpatError</code>.</p>

<p>But I also could produce at least <code>IndexError</code> and <code>AttributeError</code> just by malforming my input files. These are not documented in <code>plistlib</code>. Who knows what kind of additional errors other random input files could produce? I don't want my program to fail because of that.</p>

<p>So my question is. What should I catch? My understanding is that catching any error with a generic <code>except</code> is not preferred since it masks other errors such as <code>KeyboardInterrupt</code>. Since this is a command-line application I don't want to ignore such events.</p>

<p><strong>Code</strong>:</p>

<pre><code>import plistlib
import sys

def main():
    paths = []  # from sys.argv

    for path in paths:
        try:
            plist = plistlib.readPlist(path)
        except:  # What to catch here?
            sys.stderr.write('Couldnt read plist. Ignoring.')
            continue

        process(plist) 
</code></pre>

<p>Python 2.7, OS X.</p>

<p>If you can't do any better, then <code>except Exception:</code> avoids catching <code>KeyboardInterrupt</code> or <code>SystemExit</code>.</p>

<p>It does however catch <code>StopIteration</code> and <code>GeneratorExit</code>. Possibly you can safely move down to catching <code>StandardError</code> (which excludes those), since it would normally be considered wrong for any code other than an iterator to let <code>StopIteration</code> escape. But who knows, maybe there's some input that causes the library to call <code>next</code> on an exhausted iterator and not catch that.</p>

<p><code>StandardError</code> still catches <code>SyntaxError</code> and <code>TypeError</code>, which are often indicators of programmer error rather than bad input. But there's no single class that catches both <code>LookupError</code> and <code>MemoryError</code> (both of which would be appropriate to catch here) and not <code>SyntaxError</code>. So that's about as far as you can go without either documentation or extensive testing to determine what the code really throws.</p>

<p>Note that <code>MemoryError</code> isn't enough to know whether the error is transient (it would work on another day or another machine) or permanent (the input file is so large that no conceivable machine will be able to handle it).</p>

python python-2.7 error-handling try-catch plist