Shant Stepanian created VFS-508:
-----------------------------------

             Summary: Change FileSystemException to inherit from a 
RuntimeException, and not IOException
                 Key: VFS-508
                 URL: https://issues.apache.org/jira/browse/VFS-508
             Project: Commons VFS
          Issue Type: Improvement
            Reporter: Shant Stepanian
         Attachments: changeFileSystemToRuntime.patch

I'd like to see if we can FileSystemException to inherit from a 
RuntimeException, and not IOException

__The reason__
The reason would go back to the whole "Runtime vs. Checked" exception debate, 
and I do prefer the RuntimeException argument that with those, you have the 
choice on whether to declare the try/catch block upon usage, whereas Checked 
exceptions force that on you

In particular, I bring this up because I feel it hurts the usability of the API 
to have all operations as a checked exception. I recently looked to convert my 
code from using the regular Java JDK file api to the VFS api, and I found that 
in a number of places, I now have to add a try/catch block to handle a checked 
exception where I previously didn't have to (e.g. File.listFiles() vs. 
FileObject.getChildren(), new File("myFile") vs. 
VFS.getManager().resolveFile("myFile"))

Having one less impediment to migrate would make it easier to adopt for more 
people. As a frame of reference, Hibernate did make a change like this to 
convert HibernateException from checked to runtime, and it was fine for them


__Patch and Impact of Change__
I've attached a patch of the change - you can see it is very small, and the 
module build passes

In terms of client changes - this would only impact clients that happened to 
explicitly expect an IOException in their catch block, and not directly the 
FileSystemException. (this affected one piece of code within VFS itself, but 
could affect clients).

But I believe that this still would be a beneficial change, as it would make 
all clients' code cleaner and make it easier to adopt



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Reply via email to