Tracing back through the calls, I found "Try::Tiny". It claims to localize $@. But if it does funny things, it means the caller must use Try::Tiny as well to get sensible results! Does every try-ing module create a different dependency on its users? That would be a nightmare! I guess it "restores" it after the non-existent catch!
Using Try::Tiny, I get the thrown object in the catch block.
Even data dumper shows, in my original call, $@ to be ''. But the code branch is executed, so it is true.
As for your example, the core docs say that if eval completes without error, then $@ is guaranteed to be a null string, so you can write eval{...}; warn if $@;. You should not need to ensure your block evaluates to true, by original design of the feature.
| [reply] [Watch: Dir/Any] [d/l] [select] |
As for your example, the core docs say that if eval completes without error, then $@ is guaranteed to be a null string
Even if that would be true, then
so you can write eval{...}; warn if $@;
doesn't follow.
For the second, you also need $@ to be true if the eval fails. Which doesn't need to be the case.
The problem is end-of-scope effects. eval { } is a block. Leaving the block, whether due to reaching the end, entering a return, or because the code dies, triggers end of scope effects. Which may cause more code to be executed (think DESTROY blocks). Which may clear, or set $@.
This is a known, but hard problem to solve (as one doesn't want to lose information carried in $@). There will be improvements in 5.14, IIRC.
| [reply] [Watch: Dir/Any] [d/l] |
Re even if that were true: The eval docs state "If there was no error, $@ is guaranteed to be a null string."
| [reply] [Watch: Dir/Any] |