Olaf van der Spek wrote:
Isn't overflow more like a logic error than a runtime error? An assert might make more sense.
It typically happens in a portion of the code that can already throw because it deals with output to file. And if it were an assert, what would you do to avoid it? The same the library would do, check the value and throw if it doesn't fit. So the library just does for you what you'd have done anyway, as a convenience. As a more practical matter, users don't tend to like asserts when saving, even if this would have been the theoretically sound thing to do. :-) (For the reverse operation, where the bits are more than the value type can represent, assert doesn't seem to make sense either because we don't control the bits, which typically come from an external source.) In all this I'm assuming the buffer types, BTW. I'm not sure if the same logic would apply to the arithmetic types, because they have very different use cases. Buffers are relatively straightforward - the bits are read from file and the value is extracted, or the value is stored and the bits are written - so it's easier to reason about the context in which they are used. Arithmetics should probably just do on overflow whatever the underlying type does.