On Fri, 2005-04-22 at 12:17 -0300, pedro.lamarao@mndfck.org wrote: [snip]

I don't think it is necessary to throw an exception from the stream to signal it, for the same reason the stream can signal other kinds of errors without throwing exceptions. The standard basic_ios base class is even nice enough to offer the exceptions(iostate) "property" for you to choose if you want or don't want exceptions to be thrown. Nothing new here.

I believe a non-blocking mode is possible for std::iostream, but I'm unsure of how... elegant would it be to use it.

But should we offer the possibility for the user to set socket options, Yes.

or merely offer a blocking(bool) method?

Also, how should the stream object behave in case of EWOULDBLOCK? Set failbit? Even if we use a wouldblockbit, we still need to set failbit, as the only thing clear is that the operation was *not* successful.

I don't think you want to set failbit as it is sticky and must be manually reset and EWOULDBLOCK is not an error. /ikh