On Nov 28, 5:57 pm, Steven D'Aprano <steve +comp.lang.pyt...@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. -- http://mail.python.org/mailman/listinfo/python-list
