4 ms·
I like your example. Although I do remember that there are also read operations where you ask for 200 bytes and you can get 100 back. And it is up to the caller
by spockz 2y ago
I like your example. Although I do remember that there are also read operations where you ask for 200 bytes and you can get 100 back. And it is up to the caller to check for this. Otoh, if the socket is closed you indeed get a socket closed exception. But that is because the docker was closed while reading. What is the rust behaviour in this case?
- LoganDark 2y ago> I do remember that there are also read operations where you ask for 200 bytes and you can get 100 back. Those are read operations where you say you have 200 bytes to store the result, rather than where you ask for exactly 200 bytes. But yes, they certainly exist, the ones that ask for exact numbers of bytes are typically built on repeated calls to the ones that can return less. > Otoh, if the socket is closed you indeed get a socket closed exception. But that is because the docker was closed while reading. I think this depends on how it closed, sometimes you just get EOF, which is an error state but not an exception (unless your language is clinically insane like Python). Obviously if it's interrupted in such a way that there would probably have been more data but you can no longer get it, that's a different error than EOF (and some languages use exceptional control flow to report mere errors, it is just that Rust does not do this). > What is the rust behaviour in this case? Read calls can return less data than you asked for. If they return no data, that is a successful EOS. They can also report I/O errors as distinct from a successful result. There is an I/O error for "unexpected EOF", where you require more data than is present, and the fact that it's not present is an error. I believe `read_exact` uses this if anything happens before it has entirely filled the buffer, including completely normal connection closure.