DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37985>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37985
nichoj@gentoo.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
------- Additional Comments From nichoj@gentoo.org 2005-12-21 23:38 -------
(In reply to comment #2)
> disconnect should not be called on a SocketClient instance that has not
> been successfully connected. If there's a problem, it would be
> with the unit test, not SocketClient. In other words, the test code should be
> if(client.isConnected())
> client.disconnect();
> instead of
> client.disconnect();
> However, if you do that, then the unit test doesn't fail when a connection
> is not established. So you could write
> if(client.isConnected())
> client.disconnect();
> else
> throw SomeAppropriateException("Connection failed.");
>
> But since client.disconnect() already throws an exception, I have to assume
> the test writer opted for the shorter
> client.disconnect();
Fair enough. However, I think that some exception should be thrown (maybe
IllegalStateException?) that indicates that the object is in an invalid state,
instead of letting a NullPointerException occur.
>
> In short, the test is supposed to fail if it can't connect.
I can accept that the test would fail if it can't connect. However, it really
shouldn't be because of a NullPointerException.
(In reply to comment #3)
> I don't mean to speak for the rest of the Commons Net developers, but I think
> we'd rather you package it by bypassing the unit tests during packaging.
I concurr about not including the patch. We actually prefer to keep packages as
close to upstream as possible.
> Applying your patch may cause more bug reports from people who call disconnect()
> improperly. With the patch, they'll have no indication they did something wrong.
> We can discuss this further on commons-dev.
The current code doesn't give much better of an indication that something went
wrong, so perhaps throwing an exception, like I mentioned above, is more
appropriate?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|