[EXPERIMENT] try/catch control structure

[rjbs]

try{}catch{} was first released in perl v5.34.0 as an experimental feature. This issue tracks its progress toward the end of its experimental phase.

[rwp0]

try{}catch{} was first released in perl v5.34.0 as an experimental feature. This issue tracks its progress toward the end of its experimental phase.

addressing/identifying the features by name in contents eg. try as in use feature 'try' could be more informative for users/developers to recognize what feature it is in code

[leonerd]

The current feature is fairly minimal in its ability. In 5.35 I hope to get around to importing more abilities from Syntax::Keyword::Try.

• Typed dispatch - catch($e isa Some::X) and catch($e =~ m/^A message/)
• finally {} blocks - although perhaps those would be covered instead by defer {}

[choroba]

Also note that the feature is missing in documentation of experimental, although it is supported by it.

[Leont]

Also note that the feature is missing in documentation of experimental, although it is supported by it.

Good point, I guess I should double-check the rest too.

[boftx]

I hope this is the right place to offer a comment on the feature.

I have concerns that the new feature is using a syntax/style that breaks from the existing pattern for "eval" and Try::Tiny (and probably other as well) that allows "return" to only leave the block. I think the new practice of having it exit the surrounding method will be confusing given how well entrenched the existing behavior is. The new behavior requires using what I think has long been considered a bad practice, that of simply "falling off the bottom" in order to return a value. Granted, that is a common practice in some case, especially in Moo(se) "has" clauses for clarity, but is discouraged overall.

Also, I am curious why it was decided to base this on a module that is only used by 37 packages in CPAN (according to the reverse dependencies) as opposed to Try::Tiny which has over 1300 listed.

On a touchier note, I have the impression that the change in behavior is being made to make Perl look/feel more like other languages instead of adapting a long accepted solution to the underlying problem solved by Try::Tiny" and similar modules.

Thank you for your consideration.

[Grinnz]

For your consideration, Try::Tiny only was written not to do these things because it's not possible to do them in pure-perl; and it only has as many dependencies as it does because it was the only reasonable low-magic solution for a long time (and still is if you want to support Perl 5.10). These historical facts skew the usage in CPAN codebases, and of course should not be ignored but also should not hold hostage a feature to be less consistent with the rest of the language and user expectations (for example, if and foreach blocks which appear conceptually similar).

[boftx]

... should not hold hostage a feature to be less consistent with the rest of the language and user expectations (for example, if and foreach blocks which appear conceptually similar).

I view try/catch to be a more exact form of "eval" and so would think that the behavior of Try::Tiny is more correct. I also noticed in the original Syntax::Feature::Try that if the context variable is not supplied then the exception was available in $@, which makes me wonder if that module (and the new feature) still have the same problem that Try::Tiny resolved for the most part.

[Grinnz]

I view try/catch to be a more exact form of "eval" and so would think that the behavior of Try::Tiny is more correct.

As I said, Try::Tiny only had this behavior because there is no other option in pure-perl. It is not a form of "eval" syntax-wise because "eval" is an expression, not a statement (though it obviously shares some semantics).

SKT's usage of $@ does not cause the problems Try::Tiny is guarding against, because exceptions are indicated by running the "catch" block - Try::Tiny would frankly probably work fine using $@ itself, but that can't be changed now. $@ is more appropriate to use for a core feature in this case, though ideally most usage will assign it to a lexical variable within the "catch" block and not touch any global variables.

[boftx]

As I said, Try::Tiny only had this behavior because there is no other option in pure-perl.

FYI, I was informed by SSCAFFIDI that he wrote Try::Harder to specifically explore if Syntax::Feature::Try could be done in pure Perl and he says it was surprisingly easy to do so. So I would think that Try::Tiny, and others, kept the native behavior of "eval" because that was what was expected.

[Grinnz]

As I said, Try::Tiny only had this behavior because there is no other option in pure-perl.

FYI, I was informed by SSCAFFIDI that he wrote Try::Harder to specifically explore if Syntax::Feature::Try could be done in pure Perl and he says it was surprisingly easy to do so. So I would think that Try::Tiny, and others, kept the native behavior of "eval" because that was what was expected.

Try::Harder is a source filter, thus while easy to do, is not suitable for production code.

[hercynium]

Just to be clear - I didn’t say it was easy, just that it worked surprisingly well. In reality it was devilishly hard to get everything working just right: I actually copied the test suite from Syntax::Keyword::Try at the time and hacked on it until it passed everything but one test. IIRC, that was the “return a value” semantics, which I don’t care much for anyway. ☺

oh, and I agree my source-filter approach is way, way less than ideal, but it really was just an experiment that turned out to work well enough I think it can still be useful to provide some sort of bridge for older versions of perl.

[boftx]

Just to be clear - I didn’t say it was easy, just that it worked surprisingly well. In reality it was devilishly hard ...

Thanks for the clarification! I should have just quoted you directly on that. :)

[nrdvana]

I happened to have this little brainstorm on a Perlmonks post, and it got some upvotes, so I'm sharing it here.

This is the try/catch (or rather, catch) that I wish we had in Perl:

sub foo {
  some_code();
  catch {
     print "ignoring $@";
     say "$_ would be the exact string thrown, without 'at line…'";
  }
}

sub bar {
  some_code();
  catch ClassName::Xyz { ... }
  catch /pattern/ { ... }
  catch (ref && ref->can("info")) { ... }

  catch my $e { say $e }
  catch my $e ($e isa 'Pkg') { ... }
  catch my $e (ref($e) && ref($e)->can("info")) { ... }

  my $val= do { might_fail(); catch { 42 } };
  $val= do { might_fail(); catch { undef } } // 42;
  $val= do { might_fail(); catch } // 42;

  catch (die) { ... )  # exception within exception-test generates a warning and counts as 'false'
}

My idea of how that would play out in C-land is that as soon as the parser saw a catch, it would immediately wrap the current block's optree-in-progress with a try-context, ... and then continue as normal, attaching each consecutive catch block as a handler of that try context. I also think it should localize $_ for both the catch logical test and the catch body so that users can take advantage of all the implied "topic" operations on the exception. A lexical could be offered with the same syntax as for my $x. I think that the parentheses should be optional for the two most common cases of a isa-test and a regex. A catch could of course have no test at all and just run a block. And as a final special case, a catch could have no test and no block; and if it was the last statement it would have the effect of returning an empty list.

I'd also like it if the error string did not have the "at FILE line X" attached to it when caught, but I'm guessing that's impossible since a __DIE__ handler would be called first and it would expect to see that. I just thought I'd add it to the wishlist in case anyone thought of a way to make it happen.

[nrdvana]

Oh, and it neatly sidesteps the arguments about compatibility with expectations from Try::Tiny because

Do or do not. There is no try

^ that line needs to be in perldoc, right? That should seal the argument.