Comment by pswenson | Hacker News Reader

Comment by pswenson | Hacker News Reader

Parent Full thread

1) try introducing a Checked Exception in a commonly used method. Soon you'll be updating 100s or 1000s or methods.

2) checked exceptions don't play well with interfaces (APIs) for similar reasons. any interface user must change their code simply because some new checked exception bubbles up now

3) checked exceptions lead to terrible error handling and hiding bugs/system problems. instead of letting exceptions bubble up - java coders almost always write code that either swallows or simply logs the exception and continues along as if nothing happened. If my bank deposit fails, I don't want the failure to just end up in a log file - I want to know it! Exceptions were designed to usually bubble up and be exposed/handled in a standard way at the top level thread. They are usually not recoverable.

4) they lead to bugs. I very rarely see anyone handle the statement/resultset handling of JDBC code correctly.

5) if they are such a good idea, why does no other language ever created has them?

> 1) try introducing a Checked Exception in a commonly used method. Soon you'll be updating 100s or 1000s or methods.

Try doing that in a code base without checked exceptions. You just created 100s or 1000s of unrecognised errors in other code without realising it. The problem is not the checked exception. The problem is you changed something 100s or 1000s of things are relying on to add a new failure mode.

> Checked exceptions lead to terrible error handling and hiding bugs/system problems. instead of letting exceptions bubble up - java coders almost always write code that either swallows or simply logs ....

Well, I agree up to a point. But that is much to do with how tedious and verbose the error handling itself is which is more about the language than the concept of checked exceptions.

> they lead to bugs. I very rarely see anyone handle the statement/resultset handling of JDBC code correctly.

see above

> 5) if they are such a good idea, why does no other language ever created has them?

Well, you can also say, if they are such a bad idea, how come one of the world's most popular and used language builds them into all its core APIs? They can't be that terrible or Java would never have got so popular ....

I think you are falling into the trap of thinking you can usually recover from an exception. Exceptions are usually caused by one of two things:

1) system error (no more DB connections, hard drive full, etc)

2) a bug

neither of these are recoverable, you just need to stop the task at hand and notify someone that the situation needs to be fixed. Trying to handle it and recover is usually a fools errand that results in hiding the problem

There are cases that you do want to handle exceptions. In these cases, yes catch the exception and handle it. But these cases are the 10% case, hence the default behavior of making the caller handle the exception isn't desirable.

This link from 2003 articulates the point better than I can: http://www.artima.com/intv/handcuffs.html

If Java forced you to handle the exception that would be convincing, but it doesn't. It merely says, if you don't want to handle it, add to your signature that you throw an exception so that at least someone upstream has a chance to know that the error might occur. I'm not arguing at all btw that the way Java does it is good. Merely that there's a case for checked exceptions, especially if you are actually trying to write "reliable" software.

Depending on the software and what it's used for, the first class or errors might and should be recoverable from.

Reply on news.ycombinator.com