Re: [boost] [outcome] success-or-failure objects

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.