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
}
}
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]
