I've nothing wrong with the eval function, but I'm of the opinion that eval should be used for code that might be generated on the fly (most likely from user input), thus implying the dynamic nature of the perl language. Using eval to evaluate code that is already hard written into the code, on the other hand, seems to be a way to get around compiler/strict or other issues. Certainly there are cases where using eval on hard-coded code is necessary to achieve certain results (for example, if you have a function from a module that would die on failure, but you want to catch this), but otherwise, it reminds me of when I saw C or C++ code that was wrapped in pragmas in order to disable certain compiler features to get their badly written code working properly.
IMO, and I think it will be easier in perl 6, I'd much rather move to an OO-based Exception model as Java has, as it forces you to deal with errors, instead of allowing them to slip. This way, you can deal with errors that might be generated from one part of the code differently than errors from other parts. It does require you to think about these errors from the start, but it ends up improving your overall error-catching of the final program.
Dr. Michael K. Neylon - email@example.com
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!" It's not what you know, but knowing how to find it if you don't know that's important
eval BLOCK and eval STRING have as much in common as select FILEHANDLE has with the four-argument version, in my opinion. Since the block contents are known at compile time, they're compiled. Since string contents can't be known at compile time, they must be compiled at run time.
I do agree that using eval to catch death from the Fatal module is particularly ugly.