[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12441815 ] Niall Pemberton commented on IO-86: -----------------------------------
I see using an exception as a better mechanism for stopping the processing (unwinding from the recursively called walk method) - dropping straight out. Primarily it simplifies the walk() method by not having to to have the "lifecycle" methods return a boolean which is then checked after each of the methods that can indicate a "cancellation". This in my view makes the class easier to understand, simpler and more elegant. It also means that any of the "lifecycle" methods can initiate the cancellation and the user is not tied to a particular strategy we have decided. I think this point is important - we shouldn't have any checks for cancellation - the user puts as many/few checks as they want in whatever places. I don't understand your point about hidden dangers of a user implementing cancellation - anyone creating an implementation needs to understand how this class works and if we javadoc it well enough it should be reasonably clear what they need to do. I'm happy to put effort into that until you think it good enough. I also don't agree with your point about the exception being good design internally, but not externally. Its just a control mechanism to stop processing - no different in my mind than using booleans - just more elegant. It works both ways. If we do a full cancellation implementation that is geared only for cancellation by external processes then I think we limit the potential use of this implementation. My first use for this is not in a multi-threaded situation and cancellation would be internally initiated. I don't mind adding getters/setters for a "volatile" boolean cancelled indicator (presuming that volatile variables only have a performance hit when accessed - have't ever used them myself before) - and even a convenience method that checks and throws the cancellation execption - as long as we leave it for the user to implement the decision logic in the place that they want and the manner that they want it. That way we provode a powerful framework class that works in either circumstances (cancellation initiated either by an external process or internally). > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
