Using the Python Interpreter as a Reference

[Travis Parks]

On Nov 28, 5:57 pm, Steven D'Aprano <steve
+comp.lang.pyt... at pearwood.info> wrote:
> On Mon, 28 Nov 2011 13:29:06 -0800, Travis Parks wrote:
> > Exception handling is one of those subjects few understand and fewer can
> > implement properly in modern code. Languages that don't support
> > exceptions as part of their signature lead to capturing generic
> > Exception all throughout code. It is one of those features I wish .NET
> > had. At the same time, with my limited experience with Java, it has been
> > a massive annoyance. Perhaps something to provide or just shut off via a
> > command line parameter. What indications have there been that this has
> > been a flaw? I can see it alienating a large group of up- and-coming
> > developers.
>
> http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html
>
> Note also that Bruce Eckel repeats a rumour that checked exceptions were
> *literally* an experiment snuck into the Java language while James
> Gosling was away on holiday.
>
> http://www.mindview.net/Etc/Discussions/UnCheckedExceptionComments
>
> Even if that is not true, checked exceptions are a feature that *in
> practice* seems to lead to poor exception handling and cruft needed only
> to satisfy the compiler:
>
> http://www.alittlemadness.com/2008/03/12/checked-exceptions-failed-ex...
>
> and other annoyances. It's main appeal, it seems to me, is to give a
> false sense of security to Java developers who fail to realise that under
> certain circumstances Java will raise certain checked exceptions *even if
> they are not declared*. E.g. null pointer exceptions.
>
> See also:
>
> http://java.dzone.com/articles/checked-exceptions-i-love-you
>
> and note especially the comment from the coder who says that he simply
> declares his functions to throw Exception (the most generic checked
> exception), thus defeating the whole point of checked exceptions.
>
> --
> Steven

I think all of the examples you listed referred specifically to most
programmers finding ways around the annoyance. I have heard about
throwing generic Exception or inheriting all custom exception types
from RuntimeException. I did this quite often myself.

In general, unchecked exceptions shouldn't be caught. They occur
because of bad code and insufficient testing. Checked exceptions occur
because of downed databases, missing files, network problems - things
that may become available later without code changes.

One day, I went through about 10,000 lines of code and moved argument
checking code outside of try blocks because I realized I was handling
some of them by accident. Here is the program: if me == idiot: exit().

People don't think about this, but the exceptions thrown by a module
are part of that module's interface. Being able to make sure only what
you expect to come out is important. Unlike Java, Unit requires you to
opt in to using throws clauses. If you don't list one, one is
generated for you automatically. The benefit: you can see what a
function throws and protect yourself without all the babysitting.

A lack of exception handling is big problem in .NET. I have had
libraries from big names including Novell and Oracle throw
NullReferenceExceptions because _they_ didn't know what would happen
in cases where a DLL is missing or a dependency isn't installed. They
could have done better testing, but if the biggest names in
development can't manage to figure it, I say leave it up to the
compiler. Returning nulls or special value in cases of failures takes
us back to the days of C and Fortran.