Which incarnation of try/catch to use?

mldvx4 has asked for the wisdom of the Perl Monks concerning the following question:

Greetings.

I am now re-writing a script from scratch to change the work flow and I might as well try to modernize exception handling a bit while in there. I used to use eval { } to attempt to trap errors. I need something else capable of trapping errors which occur several layers deep in dependent Perl modules. For example, XML::RSS is getting called by XML::Feed :

Modification of non-creatable array value attempted, subscript -1 at /
+usr/share/perl5/XML/RSS.pm line 910.
[download]

However, that specific error only occurs when processing very large numbers of feeds and since eval { } can't do that, I figure it is time to check try { } catch {} or something like that.

Is there any approach which is preferred over the others for trapping exceptions?

Comment on Which incarnation of try/catch to use? Select or Download Code

Replies are listed 'Best First'.
Re: Which incarnation of try/catch to use? by Haarg (Priest) on Oct 02, 2023 at 11:29 UTC
It's not obvious what you mean by "`eval { }` can't do that". Every try/catch implementation is implemented by `eval { }` either directly or using the same internals. If `eval { }` can't do the job you need, nothing else will be able to. For a non-eval solution, I'd recommend the core "try" feature, although it is currently experimental. It's certainly more ergonomic than eval, and avoids some pitfalls regarding unusual exception objects.	[reply] [d/l] [select]
Re: Which incarnation of try/catch to use? by haukex (Archbishop) on Oct 02, 2023 at 12:29 UTC
IMHO, Try::Tiny is the "best" (simplest, most portable) module. Like Haarg, I am wondering what you mean by "`eval { }` can't do that" - one of the simplest ways to do try/catch built in to Perl is `eval { ...; 1 } or do { ... };` (but not `eval { ... }; if ($@) { ... }`!)	[reply] [d/l] [select]
Re^2: Which incarnation of try/catch to use? by mldvx4 (Friar) on Oct 03, 2023 at 07:49 UTC
Aha! There was one of the problems, I had been using `eval { ... }; if ($@) { ... }` instead of `eval { ...; 1 } or do { ... };` and the latter worked as intended, trapping the error raised in a deeper module by bad data. I've tracked down the cause of my script making the bad data now but have to redesign a bit of the work flow. After that, I folded the core "try" feature now, with good results. Although the script now warns that "try" is experimental.	[reply] [d/l] [select]
Re^3: Which incarnation of try/catch to use? by eyepopslikeamosquito (Archbishop) on Oct 03, 2023 at 08:10 UTC
Although the script now warns that "try" is experimental. See the sample code in New built-in perl5.38 try/catch syntax that silences the warning via: `# use feature 'try'; # throws 'try/catch is experimental' warnings use experimental 'try';` [download]	[reply] [d/l]
Re: Which incarnation of try/catch to use? by tobyink (Canon) on Oct 02, 2023 at 13:06 UTC
These days, `use experimental 'try'` is probably your best bet for exception handling. It will work on Perl 5.34+. If you need to support older versions, use Feature::Compat::Try. Hire me at Toby Ink Ltd or Join my OnlyFans	[reply] [d/l]
Re: Which incarnation of try/catch to use? by eyepopslikeamosquito (Archbishop) on Oct 02, 2023 at 21:14 UTC
You've already received excellent answers. If you want more reading/advice on this topic see: Re: eval to replace die? (Exceptions and Error Handling References)	[reply]
Re: Which incarnation of try/catch to use? by BillKSmith (Monsignor) on Oct 02, 2023 at 15:01 UTC
Regardless of which try/catch you choose, you should consider using object oriented exceptions (Exception::Class). They are usually overkill, but can offer a big advantage when your catch has to know which exception it is handling. The documentation is terse, but very good on how to use it, but offers little help on when. The only guidelines that I know of are in the book "Perl Best Practices". Bill	[reply]