Moments ago, quoth I:
On 10/7/2013 4:37 PM, Quoth Matt Calabrese:
If you are violating your precondition, throwing is not a proper solution for the reasons already explained several times at this point. Why the non-nullness of the pointer should be a precondition was also already explained.
I have yet to see anything that convinces me that there is a valid reason for that. Maybe I missed it, or maybe we just don't agree on this aspect of code design. :)
Just to try to head off an anticipated objection, I'll requote something else you said earlier: On 10/4/2013 4:04 AM, Quoth Matt Calabrese:
If you want unraveling of the stack or catching of the exception to be worthwhile,then you need to eliminate the precondition altogether.
I agree with that. I just think that it is indeed the correct behaviour to eliminate the precondition from the constructor (and replace it with defined behaviour to throw, and ideally to also assert). I don't like the idea of public methods (especially constructors) that make assumptions about their external input without testing it. Input can *always* be screwed up, either by user or programmer error. You can be reasonably confident about your private internal data (that's what unit tests are for). You should still assert on it, of course, because compiler/linker weirdness or memory-overwrite damage from bugs in other code can get you into a weird state, but that sort of thing truly is in UB territory and there isn't much you can do to recover from that.