commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [io] Inner class exception
Date Fri, 12 Jan 2007 05:37:04 GMT
Yeah, I'm quite interested in what the response is to having this in
the API. It's novel (for me), but could be interesting to release IO
as is and see what feedback we get from users on the feature.

Hen

On 1/11/07, James Carman <james@carmanconsulting.com> wrote:
> I can see the elegance of the design.  Personally, I don't really care
> one way or the other if you release with that in there.  I do think,
> however, that you should consider the "normal" developer out there who
> probably hasn't seen something like this before.  I've done a lot of
> coding in my days and I've never seen that done that I can remember.
> Most IDEs will automatically generate catch blocks for you anyway
> these days, but it might jump out at someone and cause some confusion.
>  Then again, maybe it'll help someone learn something new about the
> Java language. :-)  Heck it might even catch on!
>
>
> On 1/11/07, Martin Cooper <martinc@apache.org> wrote:
> > On 1/11/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:
> > >
> > > 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 <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
>
>

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