Hi,

Would it be good to add to throw a subtype exception in addition to a more 
general exception already there in the thrown list? Is it some coding style 
that's required to follow or developers can do it as they like?

It's often seen that only the general exception is in the thrown list, like in 
ReadableByteChannel#read in Oracle Java, where in fact the method may throw 4 
subtype exceptions.
http://docs.oracle.com/javase/7/docs/api/java/nio/channels/ReadableByteChannel.html
int read(ByteBuffer dst) throws IOException

In some of Hadoop codes, it goes otherwise. For example, in Hdfs.java, ref. the 
following codes, note that in the thrown list, all the former 3 exceptions 
extends IOException.
===
  @Override
  public RemoteIterator<FileStatus> listStatusIterator(final Path f)
    throws AccessControlException, FileNotFoundException,
    UnresolvedLinkException, IOException {
    return new DirListingIterator<FileStatus>(f, false) {

      @Override
      public FileStatus next() throws IOException {
        return getNext().makeQualified(getUri(), f);
      }
    };
  }
===

Doing this way, I thought the benefit could be the caller can see clearly what 
kinds of exceptions could be thrown, however in this case we can achieve it by 
adding the Javadoc. Sure there is no hurt but it looks kinds of dummy in some 
IDE, hinting some information like "There is a more general exception ... in 
the thrown list already". Given we would list all the possible exceptions, it's 
a little hard to maintain the codes.

By the way, in the above example, it looks a little weird that 
AccessControlException and UnresolvedLinkException both extend IOException. 
There is a little reason to do that for the latter, but for the former, it 
looks rather like an issue.

Please help clarify if I missed something. Thanks.

Regards,
Kai

Reply via email to