On Sunday, April 27, 2025, Jason McKesson wrote:


No. There is nothing fundamentally wrong with calling a function that
*might* throw exceptions from one that won't.

You have no idea what could cause the possibly throwing function to
throw. Maybe there are certain parameters that would cause it to throw
(nullptr, index-out-of-bounds, etc), but the non-throwing function
already did the check and no throwing can ever happen.

Unless you *know* for certain that this is not the case, you have no
right to decide for other people that this code is ill-formed.



Let's say a 3rd party library has a function as follows:

    bool RegisterMatrix(unsigned x, unsigned y) noexcept(false);

And let's say that the instruction manual says:

    Throws: An object of type 'dimensions_invalid' if 'y' is not a multiple of 'x'.

And then in your own code you invoke this function as follows:

    bool RecordAdd(unsigned const x) noexcept
    {
        return RegisterMatrix(x, x * 4u);
    }

In this instance, we know that RegisterMatrix definitely won't throw an exception because we set the 'y' argument equal to 'four times X'. So now let's try force a compiler error with 'noexcept(explicit)' as follows:

    bool RecordAdd(unsigned const x) noexcept(explicit)
    {
        return RegisterMatrix(x, x * 4u);
    }

Now the compiler refuses to compile the code because it sees a 'noexcept(false)' function called from a 'noexcept(true)' function. Here we need to tell the compiler that RegisterMatrix won't throw, perhaps by using 'std::won't_throw' as follows:

    bool RecordAdd(unsigned const x) noexcept(explicit)
    {
        return std::wont_throw( RegisterMatrix, x, x * 4u );
    }