[serialization] Incorrect assertion in basic_binary_oprimitive?
I've run into a situation where I'm triggering an assertion at basic_binary_oprimitive::save_binary(). This is on basic_binary_oprimitive.hpp, line 115 in version 1.32. This assertion seems to be claiming that an output stream will always be in a "good" state after a call to write(). On it's face, I think there's no way to safely make that claim, especially about a stream whose type is a template parameter. In fact, as I understand it, good()'s whole purpose is to let you know that the stream is busted. Am I misunderstanding something, or should that assert be changed to an exception? I'm trying to get an example program that demonstrates this problem. Currently, the code that exercises it is big and hairy, and I haven't pared down the precise conditions that cause it to happen. I can provide a stack trace, however, which may be of some use. -- Austin Bingham "If I were creating the world I wouldn't mess about with butterflies and daffodils. I would have started with lasers, eight o'clock, Day One!" Evil
Did you open the output stream with the flag ios::binary?
"Austin Bingham"
On 11/11/05, Robert Ramey
Did you open the output stream with the flag ios::binary?
Probably not, now that you mention it. I'll have to check next week when I
get back to the office.
"Austin Bingham"
news:bf1abd10511111347t18a76856i5c44b45bcb1dedfc@mail.gmail.com... I've run into a situation where I'm triggering an assertion at basic_binary_oprimitive::save_binary(). This is on basic_binary_oprimitive.hpp, line 115 in version 1.32. This assertion seems to be claiming that an output stream will always be in a "good" state after a call to write(). On it's face, I think there's no way to safely make that claim, especially about a stream whose type is a template parameter. In fact, as I understand it, good()'s whole purpose is to let you know that the stream is busted. I think its the opposite.
IIRC, Stroustrup's explanation of good() is something equivalent to "if os.good() is false, the next operation to the stream is certain to fail; if it's true, then the next operation might work". It's the equivalent of checking all of the individual error flags.
Am I misunderstanding something, or should that assert be changed to an exception? Wit this problem you'll get an exception later in any case but its more obvious to trap it here when you're debugging.
I'm not entirely clear why I should necessarily expect an exception after a stream goes bad. From what I understand, the stream itself will not throw; rather, it will silently ignore i/o calls. It looks like the serialization code itself is likely to throw after the stream goes bad, but it also looks like there might be some edge cases where it won't.
My expectation was that I would get an exception in the case of a bad stream. Assertions seem mostly useful as checks for invariates, not potentially recoverable/ignorable runtime errors. In this case, perhaps my stream is unwritable because of file permissions. An exception in this case is far preferrable to an assertion because, in many cases, a program can keep going just fine without writing some particular file. Perhaps most importantly, an assertion in this situation actually seems to make my debugging time less fruitful. That is, I'm guaranteed to never exercise some of my exception handling code in debug mode because the assertion will always be tripped. As you say, the assertion is certainly obvious, but I think it's also counterproductive in this case. Austin Bingham
participants (2)
-
Austin Bingham -
Robert Ramey