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