Re^2: Best practices for handling exceptions in die/eval style

I used similar tactics:

eval {
    # here we try
    do_smth()
} or {
    # here we catch
    ...
}
[download]

But what is about $@ clobbering? I read in MVP book about it and it seems legit that we can clobber global variable. Now I find their code right:

# Try clause
my ($error1, $error2);
{
    local $@;
    unless (eval { ...; return 1 }) {
        $error1 = 1;
        $error2 = $@;
    }
}
# Catch clause
if ($error1) {
    # handle exception
}
[download]

Comment on Re^2: Best practices for handling exceptions in die/eval style Select or Download Code

Replies are listed 'Best First'.
Re^3: Best practices for handling exceptions in die/eval style by stevieb (Canon) on Aug 29, 2018 at 22:10 UTC
Clobbering is why, years ago, I changed to the tactic I use now. The `$@` can be clobbered in some certain circumstances. The `return 1;` is the equivalent of just having `1;`... the block will return the last expression evaluated (`1`) without the explicit `return()`. If you get `undef`, you know that `eval` failed (ie. `die()`d), regardless of/if `$@` was populated or not. Localizing `$@` is definitely a wise idea if that's the route one wants to take, but it's too much code for me. Keep subs and tests tight and small, and you should be able to know what the problem is specifically, without the need of `$@`'s contents (that definitely isn't a hard rule by any stretch, so take with a grain of salt).	[reply] [d/l] [select]
Re^4: Best practices for handling exceptions in die/eval style by krautcat (Acolyte) on Aug 29, 2018 at 22:22 UTC
I appreciate your tactic and I can understand it. But it's confusing for me to ignore `$@`'s contents, I have some Python and C++ background so I prefer to create objects not messages. What if your object's method or object calls `eval` in somebody's exception handler code but it's not yours?	[reply] [d/l] [select]
Re^5: Best practices for handling exceptions in die/eval style by stevieb (Canon) on Aug 29, 2018 at 22:27 UTC
My paid profession, in part, is Python programming, so I see kind of what you're getting at here. My C++ is limited; I'm more plain C in that regard. Nonetheless, it would be great if you could come up with a Python or C++ example here (brief code example) and explain what your concerns are, everyone here would have a good base to work with and we may get a slew of good advice (I always love learning new things). Many of the Monks are proficient with several languages. I think enticing others into the equation to provide their own feedback based on a real-world working example would be great if you have the time.	[reply]
Re^6: Best practices for handling exceptions in die/eval style by krautcat (Acolyte) on Sep 05, 2018 at 22:36 UTC
Re^4: Best practices for handling exceptions in die/eval style by Anonymous Monk on Sep 06, 2018 at 00:46 UTC
When using exceptions as a method of propagating failure, as opposed to checking returns codes at every level for instance, it's very useful to know what error message or error object is in $@ in order to correctly deal with it (either in the error handling code itself at a higher level, or when you check the logs later). The defensive localization of $@ is important when your code could possibly be called from, for instance, a DESTROY sub of an object that gets destroyed while going out of a scope due to an exception being thrown.	[reply]