commons-issues mailing list archives

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

    [ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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)

Mime
View raw message