commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shevek (JIRA)" <>
Subject [jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
Date Mon, 06 Jan 2014 03:21:51 GMT


Shevek commented on VFS-508:

It's entirely recoverable. An IOException in my networking systems does not cause the application
to exit, it just waits and retries; perhaps a router was down. An IOException in my GUI does
not cause the entire application to exit. It just causes a particular button press to have
failed, and show an error dialog.

In order to implement simple behaviour like that, checked exceptions are expected. I spend
my life writing distributed networking systems, and shipping them to customers. Errors and
exceptions are the rule, not the exception, as it were. In any situation like that, I want
to know every possible error that the code can throw. Unchecked exceptions are fine for local
hacks, but nothing else.

If you really want to see how exceptions need to be handled in distributed systems, I suggest
you look at Hystrix. Of course that comes with a thread transition cost every time it's used,
so one wants to avoid it where a simpler case will satisfy. Retries are handled using C*'s
RetryStrategy. The point of checked exceptions is to allow people to write robust applications.

> Change FileSystemException to inherit from a RuntimeException, and not IOException (patch
> ---------------------------------------------------------------------------------------------------
>                 Key: VFS-508
>                 URL:
>             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

View raw message