You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2007/01/08 08:15:23 UTC
[VOTE] IO 1.3 RC1
I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1.
Available at:
http://people.apache.org/~bayard/commons-io/1.3-rc1/
Various build files, clirr/jardiff reports and the proposed site.
[ ] +1
[ ] -1
Vote to end on Friday (if it makes it that far).
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Inner class exception
Posted by Martin Cooper <ma...@apache.org>.
On 1/8/07, Stephen Colebourne <sc...@btopenworld.com> wrote:
>
> Martin Cooper wrote:
> > Could you say more about this, please? I happen to disagree on
> > exceptions as
> > inner classes being a bad idea; FileUpload has done this for years,
> without
> > any problems. But I'm always interested in hearing new perspectives...
>
> I guess its stylistic, and therefore subjective. But I see an exception
> as a critical system object, and not one that should be relegated to
> inner class status.
Inner classes are not inferior in any way, so there's no "relegation" going
on. An inner class makes perfect sense for a class that has little relevance
in isolation from another class, which is exactly the situation when you
have a exception that is tied to its enclosing class. If the exception is
specific to that class, what better way to document that than by making the
exception an inner class?
I pretty much only use inner classes for the internals of the main
> class. Details that shouldn't be exposed as part of the public API,
> except for very specialist users. Catching a cancellation exception
> doesn't seem to be a special case.
As I mentioned above, there is nothing inferior about inner classes. If you
choose to view them that way, well, that's a separate issue altogether. ;-)
--
Martin Cooper
For example, I also dislike Map.Entry, and think it should be MapEntry.
> (Well, actually I think map entries are the biggest mistake in the
> collections framework but thats another story...)
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [io] Inner class exception
Posted by Henri Yandell <fl...@gmail.com>.
On 1/9/07, Martin Cooper <ma...@apache.org> wrote:
> On 1/8/07, Henri Yandell <fl...@gmail.com> wrote:
>> .....
> Probably because you're not used to the inner class way. ;-)
Yep. Habits are bad things to get into.
> 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.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Inner class exception
Posted by Martin Cooper <ma...@apache.org>.
On 1/8/07, Henri Yandell <fl...@gmail.com> wrote:
>
> On 1/8/07, Martin Cooper <ma...@apache.org> wrote:
> > On 1/8/07, Henri Yandell <fl...@gmail.com> wrote:
> > >
> > > On 1/8/07, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > > > Martin Cooper wrote:
> > > > > Could you say more about this, please? I happen to disagree on
> > > > > exceptions as
> > > > > inner classes being a bad idea; FileUpload has done this for
> years,
> > > without
> > > > > any problems. But I'm always interested in hearing new
> perspectives...
> > > >
> > > > I guess its stylistic, and therefore subjective. But I see an
> exception
> > > > as a critical system object, and not one that should be relegated to
> > > > inner class status.
> > >
> > > +1
> > >
> > > } catch( DirectoryWalker.CancellationException ce) {
> > > ...
> > > }
> > >
> > > feels weak to me.
> >
> >
> > Weak why?
>
> Because I'm not used to it I suspect. It's not a common idiom so not
> something my eyes naturally parse, and if I was writing the code I
> suspect it would take a bit longer to write. Not char-wise, I mean in
> terms of realising what I was meant to catch.
>
> Stephen mentioned the javadoc. Looking at that, I doubt I'd be
> catching DirectoryWalker.CancellationException anyway - the method
> that it is thrown from throws IOException. The
> DirectoryWalker.CancellationException isn't in its contract, except as
> an argument passed in.
>
> The examples in the Javadoc look bad btw. They refer to CancelException
> and not
> DirectoryWalker.CancellationException.
>
> > To me, it makes the code very explicit about what is being
> > cancelled. It also, by the way, allows for other classes to have a
> > CancellationException without having to make up some other name, because
> the
> > enclosing class scopes the exception class name and allows its reuse in
> > other classes. It seems like an eminently suitable way of naming /
> scoping
> > tightly coupled classes such as we see with these types of exceptions.
>
> Good arguments - though they just make me think in terms of a more
> specific class name - "WalkCancelledException".
Probably because you're not used to the inner class way. ;-)
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.
--
Martin Cooper
Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [io] Inner class exception
Posted by Henri Yandell <fl...@gmail.com>.
On 1/8/07, Martin Cooper <ma...@apache.org> wrote:
> On 1/8/07, Henri Yandell <fl...@gmail.com> wrote:
> >
> > On 1/8/07, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > > Martin Cooper wrote:
> > > > Could you say more about this, please? I happen to disagree on
> > > > exceptions as
> > > > inner classes being a bad idea; FileUpload has done this for years,
> > without
> > > > any problems. But I'm always interested in hearing new perspectives...
> > >
> > > I guess its stylistic, and therefore subjective. But I see an exception
> > > as a critical system object, and not one that should be relegated to
> > > inner class status.
> >
> > +1
> >
> > } catch( DirectoryWalker.CancellationException ce) {
> > ...
> > }
> >
> > feels weak to me.
>
>
> Weak why?
Because I'm not used to it I suspect. It's not a common idiom so not
something my eyes naturally parse, and if I was writing the code I
suspect it would take a bit longer to write. Not char-wise, I mean in
terms of realising what I was meant to catch.
Stephen mentioned the javadoc. Looking at that, I doubt I'd be
catching DirectoryWalker.CancellationException anyway - the method
that it is thrown from throws IOException. The
DirectoryWalker.CancellationException isn't in its contract, except as
an argument passed in.
The examples in the Javadoc look bad btw. They refer to CancelException and not
DirectoryWalker.CancellationException.
> To me, it makes the code very explicit about what is being
> cancelled. It also, by the way, allows for other classes to have a
> CancellationException without having to make up some other name, because the
> enclosing class scopes the exception class name and allows its reuse in
> other classes. It seems like an eminently suitable way of naming / scoping
> tightly coupled classes such as we see with these types of exceptions.
Good arguments - though they just make me think in terms of a more
specific class name - "WalkCancelledException".
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Inner class exception
Posted by Martin Cooper <ma...@apache.org>.
On 1/8/07, Henri Yandell <fl...@gmail.com> wrote:
>
> On 1/8/07, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > Martin Cooper wrote:
> > > Could you say more about this, please? I happen to disagree on
> > > exceptions as
> > > inner classes being a bad idea; FileUpload has done this for years,
> without
> > > any problems. But I'm always interested in hearing new perspectives...
> >
> > I guess its stylistic, and therefore subjective. But I see an exception
> > as a critical system object, and not one that should be relegated to
> > inner class status.
>
> +1
>
> } catch( DirectoryWalker.CancellationException ce) {
> ...
> }
>
> feels weak to me.
Weak why? To me, it makes the code very explicit about what is being
cancelled. It also, by the way, allows for other classes to have a
CancellationException without having to make up some other name, because the
enclosing class scopes the exception class name and allows its reuse in
other classes. It seems like an eminently suitable way of naming / scoping
tightly coupled classes such as we see with these types of exceptions.
--
Martin Cooper
Either we should catch CancellationException and its
> a normal class, or we should catch IOException and it's package static
> rather than public static.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [io] Inner class exception
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 1/9/07, Henri Yandell <fl...@gmail.com> wrote:
> } catch( DirectoryWalker.CancellationException ce) {
Consider importing CancellationException and not or not only
DirectoryWalker. :-)
Jochen
--
My wife Mary and I have been married for forty-seven years and not
once have we had an argument serious enough to consider divorce;
murder, yes, but divorce, never.
(Jack Benny)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Inner class exception
Posted by Henri Yandell <fl...@gmail.com>.
On 1/8/07, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Martin Cooper wrote:
> > Could you say more about this, please? I happen to disagree on
> > exceptions as
> > inner classes being a bad idea; FileUpload has done this for years, without
> > any problems. But I'm always interested in hearing new perspectives...
>
> I guess its stylistic, and therefore subjective. But I see an exception
> as a critical system object, and not one that should be relegated to
> inner class status.
+1
} catch( DirectoryWalker.CancellationException ce) {
...
}
feels weak to me. Either we should catch CancellationException and its
a normal class, or we should catch IOException and it's package static
rather than public static.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Inner class exception
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Martin Cooper wrote:
> Could you say more about this, please? I happen to disagree on
> exceptions as
> inner classes being a bad idea; FileUpload has done this for years, without
> any problems. But I'm always interested in hearing new perspectives...
I guess its stylistic, and therefore subjective. But I see an exception
as a critical system object, and not one that should be relegated to
inner class status.
I pretty much only use inner classes for the internals of the main
class. Details that shouldn't be exposed as part of the public API,
except for very specialist users. Catching a cancellation exception
doesn't seem to be a special case.
For example, I also dislike Map.Entry, and think it should be MapEntry.
(Well, actually I think map entries are the biggest mistake in the
collections framework but thats another story...)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] IO 1.3 RC1
Posted by Martin Cooper <ma...@apache.org>.
On 1/8/07, Stephen Colebourne <sc...@btopenworld.com> wrote:
>
> -1, here's why...
>
> After reviewing the javadoc, I realised that having an inner class as an
> exception is A Bad Idea. It looks wrong in Javadoc, and will look wrong
> in code.
Could you say more about this, please? I happen to disagree on exceptions as
inner classes being a bad idea; FileUpload has done this for years, without
any problems. But I'm always interested in hearing new perspectives...
--
Martin Cooper
I propose that this exception is promoted to a top level class, and
> renamed to DirectoryWalkCancelledException.
>
> Since we need to build a new RC for Niall's fix, this shouldn't be a big
> problem if people agree.
>
> If people disagree with my analysis, then I will of course re-evaluate
> this -1 (for which I apologise...)
>
> Stephen
>
>
>
> Henri Yandell wrote:
> > I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1.
> >
> > Available at:
> >
> > http://people.apache.org/~bayard/commons-io/1.3-rc1/
> >
> > Various build files, clirr/jardiff reports and the proposed site.
> >
> > [ ] +1
> > [ ] -1
> >
> > Vote to end on Friday (if it makes it that far).
> >
> > Hen
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: [VOTE] IO 1.3 RC1
Posted by Niall Pemberton <ni...@gmail.com>.
On 1/8/07, Stephen Colebourne <sc...@btopenworld.com> wrote:
> -1, here's why...
>
> After reviewing the javadoc, I realised that having an inner class as an
> exception is A Bad Idea. It looks wrong in Javadoc, and will look wrong
> in code.
>
> I propose that this exception is promoted to a top level class, and
> renamed to DirectoryWalkCancelledException.
>
> Since we need to build a new RC for Niall's fix, this shouldn't be a big
> problem if people agree.
>
> If people disagree with my analysis, then I will of course re-evaluate
> this -1 (for which I apologise...)
I'm happy with how it is - but I also don't have an objection to you
changing it either.
Niall
> Stephen
>
> Henri Yandell wrote:
> > I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1.
> >
> > Available at:
> >
> > http://people.apache.org/~bayard/commons-io/1.3-rc1/
> >
> > Various build files, clirr/jardiff reports and the proposed site.
> >
> > [ ] +1
> > [ ] -1
> >
> > Vote to end on Friday (if it makes it that far).
> >
> > Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] IO 1.3 RC1
Posted by Stephen Colebourne <sc...@btopenworld.com>.
-1, here's why...
After reviewing the javadoc, I realised that having an inner class as an
exception is A Bad Idea. It looks wrong in Javadoc, and will look wrong
in code.
I propose that this exception is promoted to a top level class, and
renamed to DirectoryWalkCancelledException.
Since we need to build a new RC for Niall's fix, this shouldn't be a big
problem if people agree.
If people disagree with my analysis, then I will of course re-evaluate
this -1 (for which I apologise...)
Stephen
Henri Yandell wrote:
> I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1.
>
> Available at:
>
> http://people.apache.org/~bayard/commons-io/1.3-rc1/
>
> Various build files, clirr/jardiff reports and the proposed site.
>
> [ ] +1
> [ ] -1
>
> Vote to end on Friday (if it makes it that far).
>
> Hen
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE] IO 1.3 RC1
Posted by Henri Yandell <fl...@gmail.com>.
On 1/21/07, Jochen Wiedmann <jo...@gmail.com> wrote:
> On 1/8/07, Henri Yandell <fl...@gmail.com> wrote:
>
> > I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1.
>
> Very well, but what's the state?
My laptop died - but now has a new hard-drive and I'll have it back up
and running for Tuesday when unless someone jumps in earlier I plan to
work on IO, Lang, Attributes and Transaction releases.
Status for each is:
IO - Needs an RC-2 to fix one issue. Otherwise looks good to pass a
second vote. This is my priority.
Lang - Has a blocker issue, which I spent time on the plane hacking on
and it doesn't seem like an easy one to fix. The API makes it painful.
Attributes - Needs to be rebuilt such that it doesn't contain junk in
the manifest.
Transaction - Time permitting, thought I'd look at Joerg's email and
improve things in it.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] IO 1.3 RC1
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 1/8/07, Henri Yandell <fl...@gmail.com> wrote:
> I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1.
Very well, but what's the state?
--
How fast can a year go? As fast as your childs first year.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] IO 1.3 RC1
Posted by Niall Pemberton <ni...@gmail.com>.
Fixed:
http://svn.apache.org/viewvc?view=rev&revision=493980
Niall
On 1/8/07, Niall Pemberton <ni...@gmail.com> wrote:
> Everything looks good except the source distro doesn't build -
> FileFilterTestCase fails because it checks for STATUS.html in
> testFiles() - but STATUS.html isn't included in the source distro.
>
> Niall
>
> On 1/8/07, Henri Yandell <fl...@gmail.com> wrote:
> > I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1.
> >
> > Available at:
> >
> > http://people.apache.org/~bayard/commons-io/1.3-rc1/
> >
> > Various build files, clirr/jardiff reports and the proposed site.
> >
> > [ ] +1
> > [ ] -1
> >
> > Vote to end on Friday (if it makes it that far).
> >
> > Hen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] IO 1.3 RC1
Posted by Niall Pemberton <ni...@gmail.com>.
Everything looks good except the source distro doesn't build -
FileFilterTestCase fails because it checks for STATUS.html in
testFiles() - but STATUS.html isn't included in the source distro.
Niall
On 1/8/07, Henri Yandell <fl...@gmail.com> wrote:
> I've made a first release candidate of IO 1.3, tagged IO_1_3_RC1.
>
> Available at:
>
> http://people.apache.org/~bayard/commons-io/1.3-rc1/
>
> Various build files, clirr/jardiff reports and the proposed site.
>
> [ ] +1
> [ ] -1
>
> Vote to end on Friday (if it makes it that far).
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org