Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <11748232.1160607878600.JavaMail.jira@brutus>
Date: Wed, 11 Oct 2006 16:04:38 -0700 (PDT)
From: "Stephen Colebourne (JIRA)" <jira@apache.org>
To: commons-dev@jakarta.apache.org
Subject: [jira] Commented: (IO-86) Add DirectoryWalker based on FileFinder
In-Reply-To: <25486428.1153624694212.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ 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