On 1/12/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 1/12/07, James Carman <[EMAIL PROTECTED]> wrote: > "Sorry, but this doesn't seem like a very good argument to me - on > this basis you could argue against the whole existance of IO - since > it provides stuff thats not in the JDK" > > I don't know if I agree with this point, Niall. The "stuff" that's in > IO wasn't left out of the JDK because of coding style, which is the > reason Stephen (I believe that's who said it) is saying we shouldn't > use nested exception classes. I would agree that nested exception > classes should be avoided. I wouldn't want to have to qualify my > exceptions in my catch blocks:Sorry, the "existance of IO" comment was a bad attempt at "tongue in cheek humour" :-( > catch( DirectoryWalker.CancelException e ) > > That just looks ugly/weird to me and people just usually don't do > that. I would agree, however, that it does group stuff logically. OK but CancelException is primarily there to control the processing flow internally within DirectoryWalker - its a class designed to be extended and implementations that do extend it don't have to qualify the exception. When thrown it unwinds from the recursive depths and causes the handleCancelled() lifecycle method to be called. So IMO your more likely to see an implementation that does something like public class MyWalker extends DirectoryWalker { protected void handleStart(....) throws IOException { if (...) { throw new CancelException(...); } } protected void handleCancelled(...) { // my cancel processing here } }
P.S. Making it a separate class means that users will have to add an import statement for CancelException to their DirectoryWalker implementation - which as a static inner class they don't have to do - so it saves a line of code :-) Niall
The default implementation of that method does re-throw it and we have 2 scenrios for this class - cancelling internally by the process itself or cancelling by an external process. Where users handle cancellation outside of the implementation then yes they will have to use the DirectoryWalker.CancelException notation (I personally don't agree its ugly btw) - but if they don't like it they can easily re-throw their own. Niall > On 1/11/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > On 1/9/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > > From: Henri Yandell <[EMAIL PROTECTED]> > > > > > This helps with naming, but without the scoping, you're left with the > > > > > Javadocs as the only way to specify that the exception is intended to be > > > > > used only within the DirectoryWalker class. Of course, a public static inner > > > > > class can be used elsewhere as well, but the relationship with the enclosing > > > > > class makes a clear statement of intent. > > > > > > > > > > We can agree to disagree, though - I was mostly just interested in what the > > > > > arguments are against using inner classes, given that I see very clear and > > > > > meaningful reasons for using them. > > > > > > > > Ditto. Your arguments are good, so I'm quite happy to go with whatever > > > > consensus is on this one. > > > > > > I think the other argument is that the JDK doesn't have inner exception classes (well, maybe it does, but I can't think of any well-known ones ATM). Since [io] is a JDK+ library, I'd say we should have no inner exceptions. > > > > Sorry, but this doesn't seem like a very good argument to me - on this > > basis you could argue against the whole existance of IO - since it > > provides stuff thats not in the JDK :-) If you could point to a "no > > inner exceptions in the jdk" policy with reasons why then that would > > be a different thing. > > > > Two of the reasons for "inner classes" on the Sun Java tutorial[1] > > apply to this case IMO > > > > - it logically groups the exception with the class it applies to - > > i.e. DirectoryWalker > > - it makes for more readable/maintainable code > > > > >From whats been said in this thread then at the end of the day is > > purely down to different stylistic preferences. On that basis I'd > > prefer it to remain how I originally coded it. Having said that - if > > its going to prevent/hold up an IO 1.3 release then, as I said before, > > I'm not going to object to it being changed. > > > > Niall > > > > [1] http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html > > > > > > > Stephen > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
