commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: [io] Inner class exception
Date Fri, 12 Jan 2007 00:46:19 GMT
On 1/12/07, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> On 1/12/07, James Carman <james@carmanconsulting.com> 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 <niall.pemberton@gmail.com> wrote:
> > > On 1/9/07, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> > > > From: Henri Yandell <flamefew@gmail.com>
> > > > > > 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: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message