[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[
https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14905300#comment-14905300
]
Bernd Eckenfels commented on VFS-508:
-
I see arguments for both sides (and probably a deeper hirachy is needed),
however this is a API incompatible major change so it would have to wait for
3.0.
> 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.3.4#6332)
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862727#comment-13862727 ] Shevek commented on VFS-508: Please do NOT apply this patch. What most people don't understand about exceptions is that you DON'T HAVE to catch them. If an exceptional condition has occurred, and you can't handle it elegantly, just propagate it. The condition still occurred. Perhaps you have to change the type of the exception to cross a fixed API boundary, but that's minor. DO NOT hide the exception as a RuntimeException which the programmer is now allowed to be unaware of. 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)
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862733#comment-13862733 ] Shant Stepanian commented on VFS-508: - I'd ask if these exceptions that are exposed in much of the current API (specifically in the org.apache.commons.vfs2.VFS and org.apache.commons.vfs2.FileObject classes) truly warrant throwing checked exceptions that programmers must be aware of. However we accomplish this change, whether by changing the base class of FileSystemException or by changing the signatures of the VFS and FileObject classes to not throw checked exceptions, does not matter to me As an example why I don't think many of the calls in these 2 classes warrant checked exceptions, see the first one from my earlier comment: * File.listFiles() vs. FileObject.getChildren() Certainly, something can go wrong if that is called, but I'd argue that in most cases, if you cannot complete a simple getChildren call, that is probably not a recoverable error, as mentioned in Gary's first comment (step 58), and so I should not have to catch an exception for that. (much like we would not catch errors if, say, we run out of memory). Plus, the core Java API does not feel these are worthy of throwing checked exceptions, so I'd ask why these are checked exceptions in VFS This is one example, but I can certainly come up with more if needed 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)
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862741#comment-13862741 ] 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 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)
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862752#comment-13862752 ] Shant Stepanian commented on VFS-508: - I would say then whether something is recoverable depends on the use case I see your point that for distributed systems and infrastructure software, you would have to deal with this on a regular basis, and such exceptions are recoverable for your use use But my use case is for writing business application software, where our systems focus on solving operational or informational problems for our users. Here, we are not the providers of core infrastructure libraries, but the users. And so our code often would be executed either as 1) a scheduled command-line batch application that starts up periodically, runs, and exists; or 2) within a container, such as JBoss or Tomcat, that already provides the infrastructure around request handling and error processing. So to put example 2) in another way - the Tomcat code itself takes care of the error handling at the lower-levels of the stack (e.g. the network requests, HTTP handling, etc.), whereas our business code takes care of error handling at higher levels (e.g. missing business data, validation of user inputs on a UI) In terms of VFS - I would typically be able to delegate to the container that runs my code to handle lower-level failures of the file system requests. I would like to use VFS in our business apps as it does provide a useful abstraction over the file system. We often need to read file-like information from various sources (whether the raw file system, the classpath, FTP, HTTP, ...) and it would be useful to have a uniform way of accessing this data. (After all, in Enterprise IT, the big problems we are trying to solve is just how to gather information from different places and make sense of it for our users). So we would not need to or want to deal with exception handling at the level that you are for your systems. I think the level of exception handling that you do for your system is appropriate as you are writing the important core code for networking systems, whereas my code is leveraging the core infrastructure of others to write business logic without having to dive into the infrastructure code itself I do not know what other types of users currently use VFS (whether infra- or business- facing systems), but I would say that from an Enterprise IT / business IT perspective, the VFS API would be much more useful to us if these were not all checked exceptions and we were not forced to have to handle these, as the containers in which we write our code (whether simple command-line apps or J2EE) already handle it for us. And I'd say that declaring the throws block as a runtimeexception would be able to work best for all sides (infra-style code can still see the kinds of exceptions that may be thrown and handle them, whereas business IT apps would not need to deal with these for most instances) If you have additional q's on my use case, let me know 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
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862764#comment-13862764 ] Shevek commented on VFS-508: And if the container detects an error, how is it to report it to your application? Are you just looking for an exception which passes from the container filesystem routine through your code to the container top level handler? If it throws an unspecified runtime, then when you DO want to do cleanup, you either have to catch RuntimeException (which I HOPE we all agree is bad) or ...? If you're a commandline app, and you don't care, declare main() to throw Exception. If you're in J2EE, then use Throwables.propagate(). If you really don't care about exceptions (or types), use Groovy. In any case, this is a bad patch, as better solutions are available to you. 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)
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13848633#comment-13848633 ] Gary Gregory commented on VFS-508: -- Hi All: I am more concerned about using the proper abstraction than ease of use. For this I'll simply reference Joshua Block's _Effective Java_ and Chapter 9: - Item 57: Use exceptions only for exceptional conditions - Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors - and all the other items in the chapter. I think we should frame the discussion of changing VFS exceptions in these best practices or confirm that we have it right. This would also break binary compatibility with 2.0, and therefore would have to be in 3.0. I see the next (overdue!) release as 2.1. There are so many changes ready that 3.0 might be a better version number, but that's a different story. Gary 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)
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13848640#comment-13848640 ] Shant Stepanian commented on VFS-508: - Thanks for the reply - agreed on your point on how to frame the discussion To clarify my original point them - I'd say that if an API method can be debated on whether it is recoverable or not, I'd say we should default to runtime exceptions, as it allows flexibility for either case. IMO, for a framework like VFS that serves as a convenience abstraction for clients, it is the clients' usage of the API method that would say if an error is recoverable or not (at least, that has been the case for the APIs that I have used) For the two examples I gave above (VFS.getManager().resolveFile(myFile) and FileObject.getChildren()): in my use case, those were not recoverable exceptions (it was for a utility component, and I was just trying to access a directory and then read its children; if I could not find it, it was an erroneous condition). Though maybe the community here ends up viewing these 2 examples as non-recoverable across the board Look forward to hearing the discussion on this Thanks, Shant 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)
