<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If it fails, you get both a straight-forward error message and a useful<br>
traceback:<br>
<br>
Traceback (most recent call last):<br>
  File "<stdin>", line 1, in <module><br>
IOError: [Errno 2] No such file or directory: 'foomanchu'<br>
<br>
<br>
The only reason you would bother going to the time and effort of catching<br>
the error, printing your own error message, and then exiting, is if you<br>
explicitly want to hide the traceback from the user.<br></blockquote><div><br></div><div>Unfortunately, I find that even halfway technically trained (not necessarily naturally inclined or talented, but trained) users are utterly unable to read tracebacks in real world situations. I had to put up a rather big guide on how to read and interpret even the simplest ones complete with color coding, "how to pick out a traceback visually", "what line to focus your attention on (the last)", and "how trying to /read/ it instead of immediately sending it to me as if it were an opaque symbol containing secret knowledge only I can make sense of, generally saves you time in debugging issues". I'm not talking about esoteric tracebacks either resulting from real bugs and stuff. I'm talking about 'file not found' 'permission denied' IO/OS level ones that should give serious hints at things people should check/diagnose themselves.</div>

<div><br></div><div>There's a serious, "oh my god, traceback, /eyes glazed over/" reaction all around. Now these aren't unix people or command line people (except my rote), but still.</div><div><br></div>

<div>I don't quite find printing out tracebacks to stdout or stderr ever acceptable :( Especially if its an expected error condition (file not found is a very good example of that).</div><div><br></div><div>I route all my tracebacks into log files for diagnosing later (people also can not be relied upon to say anything but 'traceback' when they see one: so storing it for later is vital. They read the first word and stop. The thought of most-significant-information at the bottom is a difficult thing, alas)</div>

<div><br></div><div>Anyways. ;-) That's just my experience.</div><div><br></div><div>As to the OP: try/except is how you do it in Python. There's no shorter or easier way; exceptions are how Python handles failure-states (even soft/expected errors quite often) and it does so pervasively (but not universally).</div>

<div><br></div><div>--S</div></div>