That's not the main eval gotcha that Try::Tiny seeks to solve. Amongst the things mentioned in Try::Tiny's documentation are:

• It is possible to throw an exception which is considered false in a boolean context, thus breaking if ($@). Try::Tiny isn't fooled by that.
• If a DESTROY method calls eval then an object used within your eval could potentially clobber $@. Try::Tiny creates a copy of $@ that is safe, and passes it as a parameter to the catch block.

These errors are fairly rare in practice, but extremely difficult to figure out when they do happen. People who have been burned by them in the past tend to appreciate Try::Tiny quite a lot.

It is possible to throw an exception which is considered false in a boolean context

Don't use

if ($@)
[download]

Use

unless defined eval { somecode(); 1; }
[download]

If a DESTROY method calls eval then an object used within your eval could potentially clobber $@.

True, well, I count it as nesting evals.

UPD:

I am not trying to tell that eval is better than Try::Tiny. I just think that OP might want to temporary change one statement to see how it works with plain eval{}.

For cases when people use nested exceptions try/catch blocks, heavy use Exception handling pattern, heavy use OOP (with descructors), Try::Tiny is much better than eval{} (it's impossible to work with eval actually)

But there are valid cases when people don't need to use Exceptions/OOP in so heavy way. Then it's perfectly valid to simply use eval then. And learning eval gotchas is as hard as learning Try::Tiny gotchas.