Not putting down the way you do it, but just checking $@, particularly without checking what's in it could be problematic in some cases (ie. the variable could potentially be set during this check, unrelated to your eval(), which would technically trigger a false-positive failure). Any eval error happening in the require could also fail with an error, but your eval will reset this var to undef as soon as it starts. Here's a very similar way that does kind of the same thing, but checks the state of the eval, not whether there's an error. It also uses block eval as opposed to string eval:

BEGIN {
 
    # look for JSON::XS, and if not available, fall
    # back to JSON::PP to avoid requiring non-core modules
 
    my $json_ok = eval {
        require JSON::XS;
        JSON::XS->import;
        1;
    };
    if (! $json_ok){
        require JSON::PP;
        JSON::PP->import;
    }
}
[download]

What happens there is that if any of the lines prior to the 1; in the eval fail, the eval block will return false (undef to be specific). If all expressions within the eval succeed, the $json_ok variable will be true, and we can proceed confidently.

See a number of issues with eval in the Try::Tiny documentation (which could be, after all, a different approach to the OP's problem. To be honest, I've never used said distribution that I recall).