Hello,
a coworker discovered something that looks like an Avro C++ issue. While
I was about to sign up for Jira to report it, it was suggested to me
there to pose a question to the mailing list first.
So, there's an abstract base class avro::OutputStream, and a stream
represented by this class can be flushed by calling:
virtual void flush
<https://svn.apache.org/repos/asf/avro/site/publish/docs/1.8.1/api/cpp/html/classavro_1_1OutputStream.html#a4eba4b0bca41a7174460e2672782273d>()=0
Flushes any data remaining in the buffer to the stream's underlying
store, if any.
But what happens in case of an error? This method has a void return type
and no out parameters. (Nor does OutputStream have a way to retrieve
past error conditions.)
It would seem reasonable to assume that an implementation throws an
exception in case of failure, and that is exactly what e.g. a stream
returned by avro::fileOutputStream() does. However, as for
avro::ostreamOutputStream():
1. If exceptions are enabled on the underlying std::ostream (e.g. by
using stream.exceptions(std::ios_base::badbit)), then that underlying
stream should itself throw an exception when flushing fails, which then
gets propagated through flush().
2. However, if exceptions are not enabled on the underlying ostream,
avro::ostreamOutputStream will just ignore the error.
This seems a bit inconsistent. It would seem appropriate, in my opinion,
to at least document the current behavior, so that users know that they
should maybe turn on exceptions on the underlying stream. Or make the
stream returned by ostreamOutputStream() check for a stream error while
writing to the underlying stream and accordingly throw an exception.
(This latter behavior makes sense to me, but there's a chance that it
breaks existing code; merely adding documentation wouldn't.)
On main, commit 87212a6d47247a30dff247d16386d722c56d4390, the relevant
method is OStreamBufferCopyOut::write() in lang/c++/impl/FileStream.cc.
Opinions?
Regards,
Arne Vogel
PS: There's an unrelated bug in line 249 where the exception message for
FileBufferCopyOut::write(), on WIN32, says "read" instead of "write".
