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

Usually when modules complain about something trivial I try to suppress the noise with eval:


eval { noisy_sub_or_method() };
[download]

However when that does not work I use File::Spec and it never fails:


open STDERR, '>', File::Spec->devnull();
noisy_sub_or_method();
[download]

I don't know why eval fails sometimes or which way is more efficient to trash known and useless errors (I guess devnull).

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

Replies are listed 'Best First'.
Re^2: Best practices for handling exceptions in die/eval style by choroba (Cardinal) on Aug 30, 2018 at 00:28 UTC
What eval doesn't hide is probably just a warning, not an error: `eval { warn "Boo" };` [download] You can also hide them with `local $SIG{__WARN__} = sub {};` [download] ($q=q:Sq=~/;[c](.)(.)/;chr(-\|\|-\|5+lengthSq)`"S\|oS2"`map{chr \|+ord }map{substrSq`S_+\|`\|}3E\|-\|`7**2-3:)=~y+S\|`+$1,++print+eval$q,q,a, [download]	[reply] [d/l] [select]
Re^3: Best practices for handling exceptions in die/eval style by Anonymous Monk on Sep 06, 2018 at 01:39 UTC
This doesn't work if something prints directly to STDERR, whether from perl or C or even a forked process, in which case the above mentioned redirection to devnull would be needed. However, that method is much more difficult to localize.	[reply]