On 1/11/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: catch( DirectoryWalker.CancelException e ) That just looks ugly/weird to me and people just usually don't do that.
That depends a _lot_ on the kind of coding you're doing / exposed to. For example, it's not particularly common for web apps to use a lot of anonymous inner classes, but if you were looking at Swing code, you'd likely see them all over the place. The above may look ugly / weird to you, but it looks elegant / self-documenting to me. -- Martin Cooper I would agree, however, that it does group stuff logically.
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]
