[
https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13863879#comment-13863879
]
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
*
http://stackoverflow.com/questions/4609870/why-hibernate-changed-hibernateexception-to-runtimeexception-unchecked
(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)
*
http://stackoverflow.com/questions/864780/spring-frame-work-wraps-checked-exceptions-inside-runtimeexceptions
(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
https://www.google.com/search?q=checked+vs+unchecked+exceptions), 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
Thanks
> 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.5#6160)
