What to do of exceptions when implementing java.lang.Iterator

You should rethrow exception as custom runtime exception, not generic one, for instance SomethingBadRuntimeException. Also, you can try exception tunneling.

And I’m assured that forcing client to deal with exceptions by making them checked is a bad practice. It just pollutes your code or forces to wrap exceptions with runtime ones or force to process them in place of call but not centralized. My policy is to avoid using checked exceptions as much as possible. Consider IOException on Closable.close(): is it useful or convenient? Cases when it is are very rare, but every Java developer in the world is forced to deal with it. Most often it is swallowed or logged at best. And imagine how much this adds to code size!
There’s some posts about checked exceptions from their dark side:

  1. “Does Java need Checked Exceptions?” by Bruce Eckel
  2. The Trouble with Checked Exceptions A Conversation with Anders Hejlsberg, by Bill Venners with Bruce Eckel
  3. Java Design Flaws, C2 wiki

There are cases when checked exceptions comes to rescue. But in my opinion they are rare and usually concern to implementation of some specific module. And they don’t give very much profit.

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)