exception handling in complex Python programs

[eliben]

> >http://eli.thegreenplace.net/2008/08/21/robust-exception-handling/
>
> Just a few random points. You say:
>
> "Exceptions are better than returning error status codes. Some languages
> (like Python) leave you with no choice as the whole language core and
> standard libraries throw exceptions."
>
> Of course you have a choice. Your function can return anything you want:
>

Of course. I didn't mean that the language prohibits returning error
codes, just that you can't use it without employing exception
handling. I've fixed the wording to make it clearer.

> You also wrote:
>
> "Exceptions exist for exceptional situations: unanticipated events that
> are not a part of normal execution."
>
> Exceptions can and often are anticipated. E.g. if you write code that
> opens a URL, you better anticipate that the server might reject your
> connection. You better expect to be asked for a cookie, or
> authentication. If you check for robots.txt, you better expect that it
> might not exist. That's all normal execution.

This is a point I'm not 100% in accord with. I still think that
exceptions are for exceptional situations. I've removed the word
"unanticipated" though, because it probably has no place in that
sentence. However, I think that if one of your valid execution paths
is w/o robots.txt, you should not use an exception to check whether
it's there. This indeed uses the "bad side" of exceptions, splitting
the exetution to two paths.
Check if robots.txt is there. If it is, open it. If you can't open it,
*that* is an exception, but if it's just not there, well it's part of
your application logic. I believe this isn't against EAFP.
I'm not sure I'm making the distinction clear here, it's a fine point.

>
> "When a programmer calls str.find('substring') he doesn’t expect an
> exception to be thrown if the substring isn’t found."
>
> But if he called str.index() then he does expect an exception to be
> thrown, just like for list.index() and dict[key] can raise exceptions.
> They are neither bugs nor unexpected.
>

But why are there two versions that are the same except for the
behavior in case it wasn't found ? My wishful imagination is precisely
because of the reasons I've named. If you *know* it's there,
use .index() - then, if it fails, it's an exception, but if a part of
your logic is finding an item that might be missing, use a special
value because you want to keep the logic in a single path.

> "When used for flow-control, exceptions are like goto. There might be a
> few esoteric cases in which they’re appropriate, but 99.99% of the time
> they are not."
>
> I strongly disagree. try...except is like break or continue. Yes, it
> breaks the linear flow of control, but not in a wild, dangerous way like
> goto.
>

try...except can 'exit' to several 'catch points', unlike break/
continue. Furthermore, try...except can bring execution to another
hierarchy level if it's not caught where it's thrown, so it's much
more like goto in these senses. To find where the execution may go
you'll find yourself searhching for the exception name over your
source files, looking for the exception class name in some "except"
clause. Sounds like looking for a goto label.

P.S. Thanks a lot for taking the time to comment
Eli