[jira] [Updated] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)

["Shant Stepanian (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shant Stepanian updated VFS-508:
--------------------------------

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

I searched the JIRA and didn't see any old tickets referring to this, so I'll bring it up here

_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 code still compiles. I ran a test locally and it failed on some of the external-resource-related bits; I can follow up on this, but would like to first get your approval on this ticket before proceeding w/ any more work

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

  was:
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

        Summary: Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)  (was: Change FileSystemException to inherit from a RuntimeException, and not IOException)

> Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
> ---------------------------------------------------------------------------------------------------
>
>                 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
> I searched the JIRA and didn't see any old tickets referring to this, so I'll bring it up here
> _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 code still compiles. I ran a test locally and it failed on some of the external-resource-related bits; I can follow up on this, but would like to first get your approval on this ticket before proceeding w/ any more work
> 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)