Emmanuel Lecharny wrote:
Andrea Francia wrote:
That does not mean FtpException should not inherit from IoException.
This is
also an option.
Please, consider that I start the discussion about the exception
thrown the FileSystemView methods.
I never said that an FtpException should inherith from IOException.
I'm suggesting that it might be a good idea.
The FtpException is used every where in the project for everything.
Are all those things IOException? I think for no.
I said that I would prefer that FileSystemView uses the IOException
and the FileNotFoundException.
Niklas already explained that it won't be a good idea, and I back him
on that.
Ok for that. I'm not so convinced but maybe you're right, but this is
IMHO a minor issue.
IMHO the major issues is be more specific with the exception of the methods.
It does not mean we can't improve the current interface, by
subclassing FtpException further, depending on the cases (and I
proposed FtpFileNotFoundException, etc).
I don't understand why we should subclass FtpException.
Why all exception on the project should be a subclass of FtpException?
IMHO we need in the first place define what a FtpException is.
Apache ftpserver is a complex system with many parts, that can fails for
very different manner.
Why all those fails are of type FtpException?
IMHO the exception subclassing should be used to group similar types of
failures, not different types of failure raised from the component in
the same project.
The idea is to keep the semantic of this interface : it's really
deeply tied with FtpServer, it's _not_ a generic class, otherwise, it
would be moved to commons-io :)
IMHO the semantics of FileSystemView is ok. The only thing that I don't
understand is the use of a generic Exception.
--
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html
