commons-issues mailing list archives

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


Shant Stepanian commented on VFS-508:

To clarify, I think these methods can throw a VFS-defined exception (e.g. FileSystemException,
or a new one if FileSystemRuntimeException) that extends from RuntimeException

Thus, to answer your question on when to catch these, you can still catch the exception type
that you declare "if you choose to"; otherwise, it will propagate automatically.

This idea is not new - in fact, two of the most widely-used open source frameworks, Spring
and Hibernate, each have all their exceptions based off RuntimeExceptions, so that their frameworks
can be easy to use. See the following links for some quick reference points
(key point: Hibernate switched from checked exceptions in 2.x.x to unchecked exceptions in
3.x.x, i.e. HibernateException class itself changed its baseclass from Exception to RuntimeException)
(key point: Spring JDBC converts SQLException from Java, which is checked, to DataAccessExcpetion,
which is unchecked, so that the Spring JDBC framework is palatable for usage)

I don't want to debate this much further as these "checked-vs-unchecked-exceptions" debate
can go a while (see, so I'd
like to hear what others think also. But I'd say that converting these to runtimeexceptions
(or a subclass of RuntimeException) in VFS would make the framework that much more usable
for everyone, and we have 2 very widely-used Java frameworks as evidence that this can work
(i.e. you don't just have to take my word for it)

To respond to your other alternatives:
* Declaring main() to throw Exception is not practical, as the code that is directly going
to call the method that needs to catch a checked exception will likely not be in main, but
in a component that is called by main, or another component called from that one, ... and
so this will propagate, and becomes very ugly quickly
* Catching a specific type of RuntimeException is not bad (e.g. the DataAccessException in
Spring JDBC) if we define a standard type of exception thrown by a framework. VFS already
has this w/ FileSystemException, so this seems like a good candidate
* Groovy is not an answer either - we still need to use Java and types. And as I said, this
is not far out of left-field, as many popular Java frameworks seek to hide checked exceptions
from clients, as I am proposing here

So in the end, we have a few choices:
* The patch that I suggested
* Creating another type (e.g. FileSystemRuntimeException) and having much of the APIs in FileObject
and VFS throw this type instead (though this would break binary compatibility with version
2 even more
* Create another FileObject class that simply wraps the original FileObject class and catches
the exception, but this also seems kludgy
* Leave things status quo and not fix, and force all clients to deal w/ checked exceptions
regardless of whether they want to or not. As I said, this would make it less palable for
people to use

I'll say no more on this topic for now and see what others think. I can work around this for
now, but I would like to see this improvement as this framework is pretty useful and it would
be great for more people to use it


> 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