Re: [Boost-users] [serialization] Incorrect assertion inbasic_binary_oprimitive?

From: Austin Bingham (austin.bingham_at_[hidden])
Date: 2005-11-11 23:58:47

On 11/11/05, Robert Ramey <ramey_at_[hidden]> wrote:
>
> 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" <austin.bingham_at_[hidden]> wrote in message
> news:bf1abd10511111347t18a76856i5c44b45bcb1dedfc_at_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