commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne (JIRA)" <j...@apache.org>
Subject [jira] Commented: (IO-86) Add DirectoryWalker based on FileFinder
Date Wed, 11 Oct 2006 23:04:38 GMT
    [ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12441581 ] 
            
Stephen Colebourne commented on IO-86:
--------------------------------------

This is beginning to feel like a can of worms.

With the exception/handleCancelled combination, why do we need handleCancelled? We are asking
the user to write all the logic to determmine cancellation and handle it by throwing the exception,
so why not handle the cancellation fully at that point? Is there enough benefit to justify
the combination?

Also, I think that there may be a hidden danger/issue. A user writing a public cancel method
to be called in another thread may just throw CancellationException and expect the operation
to end, which of course it won't. Instead, they have to write all the boolean handling logic
to trap in the directory and file levels of the looping. My point here is that while an exception
is probably the right design choice in a single-threaded world for this problem, it doesn't
strike me as such in a muti-threaded world.

Perhaps this can be javadoced so users only throw CancellationException from the right thread,
but it surely makes the class riskier.

You are correct though in saying that it would allow more data to be transferred to handleCancelled().
This can be worked around using instance variables in the subclass, or handling at the point
of identifying the problem. At this point, we hit a problem of not having real-life users
yet.

So, my preferred solution is to add the boolean cancelled field to DirectoryWalker together
with a setCancelled(boolean) method. This means a full cancel solution is provided (which
is a nice value add for the class), and documented, but doesn't prevent a subclass using an
exception to achieve the same effect if it desires.

> Add DirectoryWalker based on FileFinder
> ---------------------------------------
>
>                 Key: IO-86
>                 URL: http://issues.apache.org/jira/browse/IO-86
>             Project: Commons IO
>          Issue Type: New Feature
>          Components: Utilities
>    Affects Versions: 1.2
>            Reporter: Niall Pemberton
>             Fix For: 1.3
>
>         Attachments: FileFinder.java, FileFinderTestCase.java, io-DirectoryWalker-cancellation-3.patch,
io-filefinder-start-end.patch
>
>
> I'd like to propose adding a "FileFinder" back into Commons IO. This is a simplified
version of what was recently moved out of Commons IO into the "finder" component currently
in the sandbox.
> I believe this is a simpler, more generic implementation than the finder component and
therefore would be considered suitable for inclusion in Commons IO. Although simpler it could
be used as the basis for achieving the finder component's aims - namely to emulate the unix
find command.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message