Re: [io] Inner class exception
From: Henri Yandell [EMAIL PROTECTED] 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. That would seem rather irresponsible. They will almost certainly tell us nothing. If they do oppose it then there will be nothing we can do as its backwards incompatible to change it. I would have just checked in the change last night if I wasn't so busy talking about Java 7 language changes Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On Thu, 2007-01-11 at 21:37 -0800, Henri Yandell wrote: 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. My $0.02: I'm quite happy with an Exception being a (presumably static) inner class. It's just a mechanism for namespacing, like java packages, nothing very unusual. All java programmers should be familiar with inner classes; if not, it's time they learnt :-). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [io] Inner class exception
Niall Pemberton wrote on Friday, January 12, 2007 1:44 AM:
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
[snip]
Looks reasonable for me in this case.
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/12/07, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Henri Yandell [EMAIL PROTECTED] 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. That would seem rather irresponsible. They will almost certainly tell us nothing. If they do oppose it then there will be nothing we can do as its backwards incompatible to change it. We'd know that there was opposition to it and could avoid it in other Commons libraries. So far it seems that people are tending towards liking the feature (Martin, Niall, Jörg, Simon) - with James, you and myself thinking it looks weird. James and I seem to be -0 to the feature rather than -1. So consensus so far seems to be towards leaving it in. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
Yes, I'm -0 really. As I said, I don't really care one way or the other. I just wanted to voice my opinion that it looks weird to me and we should be aware of that (not that it looks weird to me in particular, but that it could look weird to others). I know that when I look into a library I will think less of it if I see them doing something a little quirky, especially if it appears to be done just to be doing it (or to look clever). I'm not saying that's why this was done and I agree that the design is sound. I'm just thinking of outside folks and how they might perceive IO when they see something like this. On 1/12/07, Henri Yandell [EMAIL PROTECTED] wrote: On 1/12/07, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Henri Yandell [EMAIL PROTECTED] 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. That would seem rather irresponsible. They will almost certainly tell us nothing. If they do oppose it then there will be nothing we can do as its backwards incompatible to change it. We'd know that there was opposition to it and could avoid it in other Commons libraries. So far it seems that people are tending towards liking the feature (Martin, Niall, Jörg, Simon) - with James, you and myself thinking it looks weird. James and I seem to be -0 to the feature rather than -1. So consensus so far seems to be towards leaving it in. Hen - 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]
Re: [io] Inner class exception
Henri Yandell wrote: So consensus so far seems to be towards leaving it in. Well I'll remove my vote -1 then. But I still think its poor design. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
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]
Re: [io] Inner class exception
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. 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]
Re: [io] Inner class exception
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]
Re: [io] Inner class exception
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]
Re: [io] Inner class exception
On 1/12/07, Niall Pemberton [EMAIL PROTECTED] wrote:
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
}
}
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 [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]
Re: [io] Inner class exception
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 [EMAIL PROTECTED] wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: 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] - 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]
Re: [io] Inner class exception
On 1/8/07, Henri Yandell [EMAIL PROTECTED] wrote:
On 1/8/07, Martin Cooper [EMAIL PROTECTED] wrote:
On 1/8/07, Henri Yandell [EMAIL PROTECTED] wrote:
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/9/07, Martin Cooper [EMAIL PROTECTED] wrote: On 1/8/07, Henri Yandell [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
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. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/8/07, Henri Yandell [EMAIL PROTECTED] wrote:
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/8/07, Martin Cooper [EMAIL PROTECTED] wrote:
On 1/8/07, Henri Yandell [EMAIL PROTECTED] wrote:
On 1/8/07, Stephen Colebourne [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Inner class exception
On 1/9/07, Henri Yandell [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
