Generator Constructor Exception causes a Null-Pointer-Dereference

[BurningEnlightenment]

Describe the bug
If a constructor of a generator throws a Catch::GeneratorException to indicate initialization failure, the catch framework attempts to dereference a null pointer which causes the application to crash. This precludes running any test cases scheduled to run afterwards.

Expected behavior
The test application should not crash and run any remaining test cases.

Reproduction steps / MCVE

#include <catch2/catch_test_macros.hpp>
#include <catch2/generators/catch_generator_exception.hpp>
#include <catch2/generators/catch_generators.hpp>
#include <catch2/generators/catch_generators_range.hpp>

class test_generator : public Catch::Generators::IGenerator<int>
{
public:
    explicit test_generator()
    {
        // removing the following line will cause the program to terminate gracefully.
        throw Catch::GeneratorException("failure to init");
    }

    [[nodiscard]] auto get() const -> int const & override
    {
        static constexpr int value = 1;
        return value;
    }

    [[nodiscard]] auto next() -> bool override
    {
        return false;
    }
};

auto make_test_generator() -> Catch::Generators::GeneratorWrapper<int>
{
    return {new test_generator()};
}

TEST_CASE("this will segfault")
{
    // this should fail the test case, but not abort the application
    auto sample = GENERATE(make_test_generator());
    // this assertion shouldn't trigger
    REQUIRE(sample == 0U);
}

TEST_CASE("this won't run")
{
    // this assertion should trigger and be reported
    REQUIRE(1U == 0U);
}

MCVE on godbolt

Platform information:

OS	Compiler	Catch version
Win10	MSVC 14.34.31933	v3.1.1
compiler-explorer linux image	GCC 12.2	trunk/v3.2.1

Additional context
None

[horenmar]

Okay, I see the issue, I'll have to think a bit about the best way to fix this. The code as is assumes that a generator tracker will always have a generator to, well, track. However, when the generator throws an exception from the constructor, the tracker will keep existing, but won't have a generator. Then, when the test case is exited, the tracker tries to check with the generator to see if it has any more values (and so the test case should be ran again), or not.

I can probably hot-fix this by having the tracker check whether it does have a generator before trying to use it, but I am not convinced that a tracker should exist empty. The problem is that a significant refactoring would be needed to stop trackers from existing if constructing the generator fails.

[BurningEnlightenment]

I agree that an empty generator tracker doesn't sound like it should exist. I don't think a hotfix is necessary as generator constructors are usually reliable which makes this a rare edge case.