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

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).

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

Replies are listed 'Best First'.
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
Hello. It's me again. Sorry for late reply. I said about other languages just to clarify my expectations from exception handling mechanism I'll choose after discussing this topic with you and other monks. All I want is to have as close as possible exception handling strategy with objects as errors and backtraces printing to STDERR when error cannot be handled by application. Also I want to avoid all pitfalls related with language peculiarities and consider all possible edge cases, This is for elaboration best common strategy for handling exceptions in Python style (or C++), or, better, as in languages with built-in exception system on language level. I know Perl has it too by in its own way. Here is code which fails one of the tests on pre-5.14 versions. <Reveal this spoiler or all in this thread> It's one of pitfalls I want to avoid. Maybe I overlooked some other pitfalls, All I want is to take into consideration all possible pitfalls like this.	[reply] [d/l]
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]