1

Possible Duplicate:
Does close ever throw an IOException?

Can someone explain to me why socket.close() throws an IOException in Java? I seriously can not figure out how closing a socket is any different from telling the runtime to go right ahead and clean up the resources that the socket is holding onto. Is there another way of not leaking memory and cleaning up socket resources that I don't know of?

Community
  • 1
  • 1
David K.
  • 6,153
  • 10
  • 47
  • 78

2 Answers2

4

It turns out that in many cases the only time that an extant error can be communicated to the calling code is when close() is called. For example, if you have sent a UDP packet that has been rejected by the receiving computer, the only chance you have to find out about it is the next time you use that socket. If the next time you use that socket is to close it, that's when you get the exception. Note that the exception does not prevent the socket from closing, which seems to be what you're asking.

Gabe
  • 84,912
  • 12
  • 139
  • 238
  • Well that's a little silly then. If an exception doesn't prevent the socket form being closed then what is the point of throwing the exception in the first place? If I close the socket that means I don't care what's happening in the pipe anymore. If I needed to flush things or make sure that things got to their destination then I would do so before closing the socket. – David K. Jul 14 '11 at 05:09
  • How would you implement making sure that things got to their destination then? – Gabe Jul 14 '11 at 05:39
  • Wait for a certain duration for a response from the other end. If nothing comes back in that time then I'd throw an exception if necessary. Isn't that how the internet works? – David K. Jul 14 '11 at 05:43
  • 1
    @davidk01 - at the API level, no that's not how the internet works. The problem with your idea is that applications end up *waiting* for "no there wasn't an error" responses that they don't really care about. Thankfully the socket API designers didn't do that. – Stephen C Jul 14 '11 at 06:15
  • @Stephen: I'm pretty sure that's how TCP/IP works. There is no problem with my idea. If I don't care that the message got to it's destination and I call close on the socket but the API designers of Socket decided that I should get an error then they made the wrong design choice. When I call close on a socket that means I'm done and I don't care what happens in the pipe from that point on. Forcing exception handling code in instances that require no exception handling means the designers made the wrong design decisions. – David K. Jul 14 '11 at 07:45
  • 1
    @davidk01 it is not how TCP/IP works, and there are plenty of problems with your idea. @Stephen C has merely scratched the surface. In any case you are nearly 40 years too late to be complaining about it or debating wrong design choices. – user207421 Jul 14 '11 at 08:40
  • @EJP: Here you go http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmission – David K. Jul 14 '11 at 19:01
  • 1
    @davidk01 - *"When I call close on a socket that means I'm done and I don't care what happens in the pipe from that point on."*. You / your application might not care, but other people / applications NEED TO KNOW if there is a pending error to be reported. Their use-cases trump yours. – Stephen C Jul 14 '11 at 21:29
  • @davidk01 Another case: if you set a positive linger timeout, send some data, and call close, and the sending fails, the error can be reported via the close. So it has to be defined to throw an IOException. This really is how TCP/IP works, here you go: http://www.amazon.com/Fundamental-Networking-Java-Esmond-Pitt/dp/1849965455/ref=sr_1_1?s=books&ie=UTF8&qid=1310688984&sr=1-1. I wrote that. And TCP/IP is defined by RFCs, not by Wikipeda. – user207421 Jul 15 '11 at 00:18
  • @EJP: It's clear you're not getting what I'm saying. If I call close that means I'm done and the resources should be cleaned up. If I wanted to do any error checking like making sure the information got to it's destination or that the network connection didn't die on me then I would do all that before calling close on the socket. Throwing a checked exception and forcing the programmer to litter any socket code with try-catch is just retarded. You can keep your book, Wikipedia is good enough for me. – David K. Jul 15 '11 at 01:52
  • 1
    @davidk01 it's clear you're not getting what @Stephen C and I are saying. There are circumstances in which TCP wants to report an error on close. Therefore close() must throw an IOException. If you personally don't care, ignore it. Feel free. But that doesn't entitle you to redesign the API so nobody can ever discover those errors. And there is nothing in Wikipedia that contradicts anything I have said here, or rather if there is it is wrong. And I wasn't offering my book actually, you have to pay for it. – user207421 Jul 15 '11 at 08:24
2

One case ... a socket that has not been opened.

Manuel Salvadores
  • 16,287
  • 5
  • 37
  • 56