On 24/01/2018 10:25, Niall Douglas wrote:
I'd now go so far as to assert - not even claim - that if you're throwing logic-error-type-exceptions in brand new C++ 14 or 17 library code, you're doing something very wrong. It's a design pattern which imposes considerable costs on your users, and for very little gain when there are so many better alternatives available in today's tooling and support libraries.
Cue now some of said sizeable number of people who think that I am dead wrong on that assertion ...
I don't think you're wrong, but I do think you have the rose-tinted glasses on a little too tightly. For libraries that have the luxury of building cross-platform and running UBSan, sure. For large applications that want to use those libraries and contain too many Windows-isms to build with UBSan, *especially* in domains where crashing the process has significant (though not life threatening to the point of requiring certification) consequences, having the option to throw an exception on precondition violation seems preferable to more subtle UB issues. BOOST_ASSERT seems like a good compromise on that front; it can be configured to assert in debug mode and either vanish entirely in release mode (for the folks who can rely on UBSan) or throw exceptions (for everyone else). Policies like Outcome has can be even better, but take more work to get right, and sometimes don't put the knobs in the right places when used indirectly.