2008/10/2 Steve Ulrich <[EMAIL PROTECTED]>: > Hi! > >> Niklas Gustavsson [mailto:[EMAIL PROTECTED] wrote >> >> Yes, I'm aware that we can chain and replace exceptions thrown by the >> various protocols, that was not my concern. My question was if >> IOExceptions semantics matches the error conditions that we talk about >> here. From the Javadoc: "Signals that an I/O exception of some sort >> has occurred". I'm not sure if this is true for many of the cases >> where the FtpServer file system abstraction fails. But then again, >> this might be a case of splitting hairs. What do the rest of you >> think? > > > Using IOException for anything not IO related isn't a good practice. I/O mean input/oputput, it does not cover only the I/O to real filesystem it cover also I/O trough the net sockets, the RemoteException used in RMI is an IOException.
An error that occour while accessing to a virtual file system for me is equal to an error that occour in a real filesystem. In the standard java library all error that occour accessing to a real filesystem are IOException. > If there's really an IOException the implementation must cleanup the IO > resources! Which implementation? the FileSystemView implementation or the FileSystemView client code? > Misusing IOException will lead to confusion and zombie connections/IO > resources. I'm not conviced, how this should happen (in the given case)? -- Andrea Francia http://andreafrancia.blogspot.com/
