In message <[EMAIL PROTECTED]>, Jason Mathews writes: >But checking if a socket is null in the close() for example is good >practice. Often a programmer will close the Socket, JDBC connection, etc >in a finally block whether or not is was or still is connected. The >Socket or SocketClient class in this case knows whether it is open and >thowing a NullpointerException does not seem right to me.
Okay, so if I understand correctly, you're saying there's a common and reasonable use case where close() may be called two or more times in succession. That's definitely reasonable. The only thing I would say then is that we should be consistent and make sure we perform these safety checks in all of the protocol client classes. Adding them to SocketClient and DatagramSocketClient should cover most of them (off the top of my head I don't know which ones override close(), but they probably call super.close() anyway). I'm still iffy on the isOpen and isConnected checks, but if we're going to go that way I would vote for throwing an exception. At any rate, I'm persuaded, so unless anyone else has any concerns, I'll apply the patch in the next few days (let's say after Wednesday to allow some time for others to offer their views), except with the change that the isOpen() check results in the throwing of an exception and I'll also make sure all of the protocol classes behave similarly. I think it's okay to apply these changes right now since they aren't new feature additions. But if anyone thinks we should hold off and do the 1.1 release first, just say the word. I think we've applied all of the pending changes we agreed to a month or so ago. Thanks for your contribution(s) Jason! daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
