Subject: Re: [boost] [outcome] success-or-failure objects
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-01-23 22:30:27
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.