Mailing List Archive

Adding a try/catch syntax to Perl
I intend to add try/catch syntax. This has been one of the most
frequently-requested of core syntax features - from both community
sources like Freenode #perl and other core developers - so I do not
anticipate this will be a contentious or debated idea.

As many of the existing CPAN solutions all follow a very similar theme
- including my own Syntax::Keyword::Try[1] - I expect I shall follow
that pattern, and likewise do not anticipate that this will be
considered controversial. Syntax::Keyword::Try has been the preferred
module by Freenode #perl for a while now, and folks seem happy with it.

I further intend it to be introduced as

use feature 'try';

Towards this goal, I have created a module Feature::Compat::Try[2] to
simplify migration. Existing authors can

use Feature::Compat::Try;

in their current code, today, and import a configured version of
Syntax::Keyword::Try which works on all Perl versions back to 5.16, and
conforms exactly to the specification of the thing I want to add to
core. (S:K:T additionally contains other features, experimental ideas,
and past mistakes, that I do not intend to bring in at this time, hence
the configuration).

A brief summary, from its synopsis, is:

use Feature::Compat::Try;

sub foo
{
try {
attempt_a_thing();
return "success";
}
catch ($e) {
warn "It failed - $e";
return "failure";
}
}

If anyone wishes to review in more detail the syntax and semantics,
please read the documentation and unit-tests of this module. That is
what I intend to implement exactly. You do not have to wait until I
have a PR to actually implement it to do this - the earlier you do
this, the better :)


1: https://metacpan.org/pod/Syntax::Keyword::Try

2: https://metacpan.org/pod/Feature::Compat::Try

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Adding a try/catch syntax to Perl [ In reply to ]
This mail is cross-posted to github at

https://github.com/Perl/perl5/issues/18504

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Adding a try/catch syntax to Perl [ In reply to ]
Please change *catch ($e)* to *catch $e *so that millions of people in the
decades to come do not have to waste thousands of man years of effort
struggling to correctly parse and place pointless parentheses when a small
amount of extra programming effort eftsoon could easily eradicate this evil
necessity in its entirety and thereby save us all a lot of time. "Tempus
fugit". "Ha una vita sola".


On Fri, Jan 22, 2021 at 5:02 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> I intend to add try/catch syntax. This has been one of the most
> frequently-requested of core syntax features - from both community
> sources like Freenode #perl and other core developers - so I do not
> anticipate this will be a contentious or debated idea.
>
> As many of the existing CPAN solutions all follow a very similar theme
> - including my own Syntax::Keyword::Try[1] - I expect I shall follow
> that pattern, and likewise do not anticipate that this will be
> considered controversial. Syntax::Keyword::Try has been the preferred
> module by Freenode #perl for a while now, and folks seem happy with it.
>
> I further intend it to be introduced as
>
> use feature 'try';
>
> Towards this goal, I have created a module Feature::Compat::Try[2] to
> simplify migration. Existing authors can
>
> use Feature::Compat::Try;
>
> in their current code, today, and import a configured version of
> Syntax::Keyword::Try which works on all Perl versions back to 5.16, and
> conforms exactly to the specification of the thing I want to add to
> core. (S:K:T additionally contains other features, experimental ideas,
> and past mistakes, that I do not intend to bring in at this time, hence
> the configuration).
>
> A brief summary, from its synopsis, is:
>
> use Feature::Compat::Try;
>
> sub foo
> {
> try {
> attempt_a_thing();
> return "success";
> }
> catch ($e) {
> warn "It failed - $e";
> return "failure";
> }
> }
>
> If anyone wishes to review in more detail the syntax and semantics,
> please read the documentation and unit-tests of this module. That is
> what I intend to implement exactly. You do not have to wait until I
> have a PR to actually implement it to do this - the earlier you do
> this, the better :)
>
>
> 1: https://metacpan.org/pod/Syntax::Keyword::Try
>
> 2: https://metacpan.org/pod/Feature::Compat::Try
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>


--
Thanks,

Phil <https://metacpan.org/author/PRBRENAN>

Philip R Brenan <https://metacpan.org/author/PRBRENAN>
Re: Adding a try/catch syntax to Perl [ In reply to ]
FWIW, I personally prefer the parens. It matches what I expect from JS, at least, and it fits things like the “isa” feature of Syntax::Keyword::Try.

-FG

> On Jan 22, 2021, at 1:34 PM, Philip R Brenan <philiprbrenan@gmail.com> wrote:
>
> Please change catch ($e) to catch $e so that millions of people in the decades to come do not have to waste thousands of man years of effort struggling to correctly parse and place pointless parentheses when a small amount of extra programming effort eftsoon could easily eradicate this evil necessity in its entirety and thereby save us all a lot of time. "Tempus fugit". "Ha una vita sola".
>
>
> On Fri, Jan 22, 2021 at 5:02 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
> I intend to add try/catch syntax. This has been one of the most
> frequently-requested of core syntax features - from both community
> sources like Freenode #perl and other core developers - so I do not
> anticipate this will be a contentious or debated idea.
>
> As many of the existing CPAN solutions all follow a very similar theme
> - including my own Syntax::Keyword::Try[1] - I expect I shall follow
> that pattern, and likewise do not anticipate that this will be
> considered controversial. Syntax::Keyword::Try has been the preferred
> module by Freenode #perl for a while now, and folks seem happy with it.
>
> I further intend it to be introduced as
>
> use feature 'try';
>
> Towards this goal, I have created a module Feature::Compat::Try[2] to
> simplify migration. Existing authors can
>
> use Feature::Compat::Try;
>
> in their current code, today, and import a configured version of
> Syntax::Keyword::Try which works on all Perl versions back to 5.16, and
> conforms exactly to the specification of the thing I want to add to
> core. (S:K:T additionally contains other features, experimental ideas,
> and past mistakes, that I do not intend to bring in at this time, hence
> the configuration).
>
> A brief summary, from its synopsis, is:
>
> use Feature::Compat::Try;
>
> sub foo
> {
> try {
> attempt_a_thing();
> return "success";
> }
> catch ($e) {
> warn "It failed - $e";
> return "failure";
> }
> }
>
> If anyone wishes to review in more detail the syntax and semantics,
> please read the documentation and unit-tests of this module. That is
> what I intend to implement exactly. You do not have to wait until I
> have a PR to actually implement it to do this - the earlier you do
> this, the better :)
>
>
> 1: https://metacpan.org/pod/Syntax::Keyword::Try
>
> 2: https://metacpan.org/pod/Feature::Compat::Try
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>
>
> --
> Thanks,
>
> Phil
>
> Philip R Brenan
Re: Adding a try/catch syntax to Perl [ In reply to ]
The parentheses also enable future extensions with arbitrary syntax such as
typed dispatch.

-Dan

On Fri, Jan 22, 2021 at 1:38 PM Felipe Gasper <felipe@felipegasper.com>
wrote:

> FWIW, I personally prefer the parens. It matches what I expect from JS, at
> least, and it fits things like the “isa” feature of Syntax::Keyword::Try.
>
> -FG
>
> > On Jan 22, 2021, at 1:34 PM, Philip R Brenan <philiprbrenan@gmail.com>
> wrote:
> >
> > Please change catch ($e) to catch $e so that millions of people in the
> decades to come do not have to waste thousands of man years of effort
> struggling to correctly parse and place pointless parentheses when a small
> amount of extra programming effort eftsoon could easily eradicate this evil
> necessity in its entirety and thereby save us all a lot of time. "Tempus
> fugit". "Ha una vita sola".
> >
> >
> > On Fri, Jan 22, 2021 at 5:02 PM Paul "LeoNerd" Evans <
> leonerd@leonerd.org.uk> wrote:
> > I intend to add try/catch syntax. This has been one of the most
> > frequently-requested of core syntax features - from both community
> > sources like Freenode #perl and other core developers - so I do not
> > anticipate this will be a contentious or debated idea.
> >
> > As many of the existing CPAN solutions all follow a very similar theme
> > - including my own Syntax::Keyword::Try[1] - I expect I shall follow
> > that pattern, and likewise do not anticipate that this will be
> > considered controversial. Syntax::Keyword::Try has been the preferred
> > module by Freenode #perl for a while now, and folks seem happy with it.
> >
> > I further intend it to be introduced as
> >
> > use feature 'try';
> >
> > Towards this goal, I have created a module Feature::Compat::Try[2] to
> > simplify migration. Existing authors can
> >
> > use Feature::Compat::Try;
> >
> > in their current code, today, and import a configured version of
> > Syntax::Keyword::Try which works on all Perl versions back to 5.16, and
> > conforms exactly to the specification of the thing I want to add to
> > core. (S:K:T additionally contains other features, experimental ideas,
> > and past mistakes, that I do not intend to bring in at this time, hence
> > the configuration).
> >
> > A brief summary, from its synopsis, is:
> >
> > use Feature::Compat::Try;
> >
> > sub foo
> > {
> > try {
> > attempt_a_thing();
> > return "success";
> > }
> > catch ($e) {
> > warn "It failed - $e";
> > return "failure";
> > }
> > }
> >
> > If anyone wishes to review in more detail the syntax and semantics,
> > please read the documentation and unit-tests of this module. That is
> > what I intend to implement exactly. You do not have to wait until I
> > have a PR to actually implement it to do this - the earlier you do
> > this, the better :)
> >
> >
> > 1: https://metacpan.org/pod/Syntax::Keyword::Try
> >
> > 2: https://metacpan.org/pod/Feature::Compat::Try
> >
> > --
> > Paul "LeoNerd" Evans
> >
> > leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> > http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
> >
> >
> > --
> > Thanks,
> >
> > Phil
> >
> > Philip R Brenan
>
>
Re: Adding a try/catch syntax to Perl [ In reply to ]
On Fri, 22 Jan 2021 13:47:52 -0500
Dan Book <grinnz@gmail.com> wrote:

> The parentheses also enable future extensions with arbitrary syntax
> such as typed dispatch.

^-- yes, that.

I have been thinking several steps ahead here. While not a part of my
*current* proposal for core, I do aim that one day we can

try { ... }
catch ($e isa MyApp::SomeWeirdException) { ... }
catch ($e isa Perl::X::ENOENT) { ... }
catch ($e) { default here }

So the parens are necessary for those later forward steps.

If you want to see the full and varied discussions about the history of
that part of Syntax::Keyword::Try, see [while rt.cpan.org is still a
thing]:

https://rt.cpan.org/Ticket/Display.html?id=123918

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Adding a try/catch syntax to Perl [ In reply to ]
Might it be better to have the exception in *$@* as "in the best it is"?
This would save updates to documentation, reduce user confusion and allow
the *($e)* to be dispensed with entirely in the most common use cases. Of
course if one wishes to spend one's time needlessly typing parentheses, we
should all defend to the death the absolute right to do so. But for those
of us who prefer to get on with life and opt to use Perl because it is the
most expressive of languages, because it is not only not Java nor
Javascript but is in fact something altogether brighter and better, if a
small amount of programming could save so much effort, then "If t'wer
done, when tis done, t'were well it were done quickly" would be seem to be
the best solution by far for the mortal rest of us. "Chi vorrebbe
caricarsi di grossi fardelli ... "

On Fri, Jan 22, 2021 at 7:09 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Fri, 22 Jan 2021 13:47:52 -0500
> Dan Book <grinnz@gmail.com> wrote:
>
> > The parentheses also enable future extensions with arbitrary syntax
> > such as typed dispatch.
>
> ^-- yes, that.
>
> I have been thinking several steps ahead here. While not a part of my
> *current* proposal for core, I do aim that one day we can
>
> try { ... }
> catch ($e isa MyApp::SomeWeirdException) { ... }
> catch ($e isa Perl::X::ENOENT) { ... }
> catch ($e) { default here }
>
> So the parens are necessary for those later forward steps.
>
> If you want to see the full and varied discussions about the history of
> that part of Syntax::Keyword::Try, see [while rt.cpan.org is still a
> thing]:
>
> https://rt.cpan.org/Ticket/Display.html?id=123918
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>


--
Thanks,

Phil <https://metacpan.org/author/PRBRENAN>

Philip R Brenan <https://metacpan.org/author/PRBRENAN>
Re: Adding a try/catch syntax to Perl [ In reply to ]
If we had an LR parser in play that did not require an early commitment to
the rule to be expanded, instead of an LL one that does, we could offer the
more expressive:

{...} fail {...}

where *fail* is a dyadic operator linking the *try* part to the *catch*
part.

But of course that would be advanced language technology that transcended
Java or Javascript when our goal, these days, is, apparently, to be as much
like them as possible, yea verily, right down to the very last parenthesis:

We are not now that strength which in old days
Moved earth and heaven;


On Fri, Jan 22, 2021 at 7:09 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Fri, 22 Jan 2021 13:47:52 -0500
> Dan Book <grinnz@gmail.com> wrote:
>
> > The parentheses also enable future extensions with arbitrary syntax
> > such as typed dispatch.
>
> ^-- yes, that.
>
> I have been thinking several steps ahead here. While not a part of my
> *current* proposal for core, I do aim that one day we can
>
> try { ... }
> catch ($e isa MyApp::SomeWeirdException) { ... }
> catch ($e isa Perl::X::ENOENT) { ... }
> catch ($e) { default here }
>
> So the parens are necessary for those later forward steps.
>
> If you want to see the full and varied discussions about the history of
> that part of Syntax::Keyword::Try, see [while rt.cpan.org is still a
> thing]:
>
> https://rt.cpan.org/Ticket/Display.html?id=123918
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>


--
Thanks,

Phil <https://metacpan.org/author/PRBRENAN>

Philip R Brenan <https://metacpan.org/author/PRBRENAN>
Re: Adding a try/catch syntax to Perl [ In reply to ]
On Fri, 22 Jan 2021 20:42:11 +0000
Philip R Brenan <philiprbrenan@gmail.com> wrote:

> Might it be better to have the exception in *$@* as "in the best it
> is"? This would save updates to documentation, reduce user confusion
> and allow the *($e)* to be dispensed with entirely in the most common
> use cases.

$@ is well-known to be extremely fragile, a variable whose value is
prone to being changed underneath you without provocation. It is best
avoided. In fact it can be considered similar to the original form of
`foreach` without a lexical var, simply aliasing the `$_` variable. Too
often you end up accidentally mutating that variable and hence the
original value in the array. The use of lexicals `foreach my $VAR` was
added to make that much safer.


It is the avoidance of this which lead to the design of `catch (VAR)`
in the first place. Originally SKT just did try/catch with no var,
expecting the user to read from $@ as you described. Quickly in use it
turned out everyone just did

catch {
my $e = $@;
... # use $e and ignore $@

all the time, to avoid the volatility of $@.

Around SKT version 0.12 I added `catch my $VAR` syntax to simplify
this.

It was later found that that doesn't play well with the typed dispatch
idea, whereas `catch ($VAR)` does; which was then added in 0.14, and
the previous form marked deprecated.

Version 0.18 de-experimentalises the `catch (VAR)` form. I notice that
`catch my $VAR` has been totally removed from the code, though it seems
I did not record in the Changes file when that occurred.

You can read for yourself at

https://metacpan.org/source/PEVANS/Syntax-Keyword-Try-0.21/Changes

Please acquaint yourself with the mistakes of history, so that you are
not doomed to repeat them.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Adding a try/catch syntax to Perl [ In reply to ]
On Fri, 22 Jan 2021 20:58:33 +0000
Philip R Brenan <philiprbrenan@gmail.com> wrote:

> If we had an LR parser in play that did not require an early
> commitment to the rule to be expanded, instead of an LL one that
> does, we could offer the more expressive:
>
> {...} fail {...}
>
> where *fail* is a dyadic operator linking the *try* part to the
> *catch* part.

It turns out that LR grammars are quite brutal on humans as well as
computer parsers.

One of the points of upfront try/catch notation is that it alerts the
reader, when scanning down the code in the usual top-to-bottom fashion,
that something fun is happening with respect to exception handling.
Otherwise, you can be mislead as to the nature of the behaviour if you
get a long piece of code that reads

{
... # 50 lines of code here
} fail {
...
}

once you skip past those 50 lines and realise what was going on.

In the sphere of natural languages there is the concept of a "garden
path sentence"; to quote Wikipedia on the subject:

A garden-path sentence is a grammatically correct sentence that
starts in such a way that a reader's most likely interpretation will
be incorrect; the reader is lured into a parse that turns out to be a
dead end or yields a clearly unintended meaning.
-- https://en.wikipedia.org/wiki/Garden-path_sentence

"The horse raced past the barn fell." has always been my favourite of
these. As perhaps you can tell by reading it aloud, it causes some
mental upset when you have to reparse what it meant.

I would consider it rude of a language to encourage programmers to
write such programs, even if we can theoretically parse them.

(It is also for this reason I considered but rejected a Raku-style
embedded CATCH {} phaser block inside a regular one.)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Adding a try/catch syntax to Perl [ In reply to ]
One of the many advantages of the *fail* syntax:

{ A...} *fail* {B ....} *fail* {C ....} *fail* { {D ....} *fail* {E ....}
}

Is that it can be easily chained and nested in order to express the idea
that the code designed to handle the failure is every bit as likely to fail
as the code thought likely to fail.

Proof by contradiction: If you can write code in the catch block that does
not fail then why can you not write code in the try block that does not
fail in the first place and thereby obviate the need for a try/catch at all?

It also lends itself well to use in expressions:
a / b fail NaN
allowing us to avoid discrimination against expressions over statements.

It is easy to teach and document because it is minimal: there is no
plethora of extraneous keywords and parentheses to explain to the student.

By using a more expressive syntax we move gracefully ahead of the
competition: we give people a reason to write Perl in a syntax so
beautifully free of any unwanted parentheses and keywords that they look
upon the messy alternatives provided by the lesser languages with horror.

G. H. Hardy: Beauty is the first test: there is no permanent place in the
world for ugly mathematics (or programming languages).

Ludwig Wittgenstein: “Die Grenzen meiner Sprache bedeuten die Grenzen
meiner Welt.”
Re: Adding a try/catch syntax to Perl [ In reply to ]
On Sat, 23 Jan 2021 14:31:18 +0000
Philip R Brenan <philiprbrenan@gmail.com> wrote:

> One of the many advantages of the *fail* syntax:
>
> { A...} *fail* {B ....} *fail* {C ....} *fail* { {D ....} *fail* {E
> ....} }
<snip>...

You are continuing to describe a design quite apart from that which has
been created time and time again, both in many other languages, and
within Perl as either pureperl or syntax modules:

https://metacpan.org/pod/Try
https://metacpan.org/pod/Nice::Try
https://metacpan.org/pod/Try::Tiny
https://metacpan.org/pod/Try::Catch
https://metacpan.org/pod/Try::Harder
https://metacpan.org/pod/Syntax::Feature::Try
https://metacpan.org/pod/Syntax::Keyword::Try
et.al.

I have designed this core feature based on the massively overwhelming
precedent given by all those modules, which everyone seems to be
creating and using. Of the above list, Try::Tiny alone has 1,255
reverse dependencies (that is, other modules which depend on it). I
think that is sufficient to say this particular design is popular.

By all means feel free to pursue your `fail` idea - there is no doubt
room for multiple different ways to do things in Perl, after all.

I just observe that the people demand a try{}-shaped cake, so I shall
let them eat it.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Adding a try/catch syntax to Perl [ In reply to ]
On 23/01/2021, Philip R Brenan wrote:



> Proof by contradiction: If you can write code in the catch block that
> does not fail then why can you not write code in the try block that
> does not fail in the first place and thereby obviate the need for a
> try/catch at all?

Code might fail because a resource is unavailable, and so failure might be
exactly the right outcome.





Regards
Re: Adding a try/catch syntax to Perl [ In reply to ]
+1 from me in the proposed form without the changes suggested in the thread
(Keep the parens).

-Chad

On Fri, Jan 22, 2021 at 9:02 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> I intend to add try/catch syntax. This has been one of the most
> frequently-requested of core syntax features - from both community
> sources like Freenode #perl and other core developers - so I do not
> anticipate this will be a contentious or debated idea.
>
> As many of the existing CPAN solutions all follow a very similar theme
> - including my own Syntax::Keyword::Try[1] - I expect I shall follow
> that pattern, and likewise do not anticipate that this will be
> considered controversial. Syntax::Keyword::Try has been the preferred
> module by Freenode #perl for a while now, and folks seem happy with it.
>
> I further intend it to be introduced as
>
> use feature 'try';
>
> Towards this goal, I have created a module Feature::Compat::Try[2] to
> simplify migration. Existing authors can
>
> use Feature::Compat::Try;
>
> in their current code, today, and import a configured version of
> Syntax::Keyword::Try which works on all Perl versions back to 5.16, and
> conforms exactly to the specification of the thing I want to add to
> core. (S:K:T additionally contains other features, experimental ideas,
> and past mistakes, that I do not intend to bring in at this time, hence
> the configuration).
>
> A brief summary, from its synopsis, is:
>
> use Feature::Compat::Try;
>
> sub foo
> {
> try {
> attempt_a_thing();
> return "success";
> }
> catch ($e) {
> warn "It failed - $e";
> return "failure";
> }
> }
>
> If anyone wishes to review in more detail the syntax and semantics,
> please read the documentation and unit-tests of this module. That is
> what I intend to implement exactly. You do not have to wait until I
> have a PR to actually implement it to do this - the earlier you do
> this, the better :)
>
>
> 1: https://metacpan.org/pod/Syntax::Keyword::Try
>
> 2: https://metacpan.org/pod/Feature::Compat::Try
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>
Re: Adding a try/catch syntax to Perl [ In reply to ]
I will repeat my objections against try/catch syntax from code maintenance
point of view (assuming that maintenance is 80% of code base life-cycle)

try / catch is type of construct where usually huge chunk of code comes
before smaller one.
It's common rule to put smaller parts ahead of larger parts in if
statement, so why not to do same with exception handing?

You are working on FINALLY block. So implement CATCH (condition) BLOCK same
way (valid since declaration).
At the end result code will be:
- declare how to handle unexpected behaviour (aka: install handler)
- do something

Behaviour will be consistent with signal handling, even you can extend this
syntax into CATCH (SIGNAL::FOO)

It will be also nice to have conditional exception handling (including
FINALLY):
CATCH (connection error) { sleep 10; redo; } if $retry_allowed;

and last but not least: you can easily implement less expressive variant
(try/catch/finally) using FINALLY / CATCH blocks

Example (pseudo code):
sub q {
CATCH (DBI::Connection::Error) { ... }
my $dbh = connect;
FINALLY { $dbh->disconnect }

CATCH (no rows selected exception) { return; }
CATCH (sql exception) { $log->log; redo BLOCK; }

BLOCK:
$dbh->do (...);
}
Re: Adding a try/catch syntax to Perl [ In reply to ]
On Wed, 27 Jan 2021 12:54:48 +0100
Branislav Zahradník <happy.barney@gmail.com> wrote:

> I will repeat my objections against try/catch syntax from code
> maintenance point of view (assuming that maintenance is 80% of code
> base life-cycle)

And I will repeat my replies to them.

> try / catch is type of construct where usually huge chunk of code
> comes before smaller one.
> It's common rule to put smaller parts ahead of larger parts in if
> statement, so why not to do same with exception handing?

See my comments I made to Philip Brenan about "Garden Path Sentences";
to wit:


That verymuch applies here too.

> You are working on FINALLY block. So implement CATCH (condition)
> BLOCK same way (valid since declaration).
> At the end result code will be:
> - declare how to handle unexpected behaviour (aka: install handler)
> - do something

FINALLY blocks are in quite a different category; and indeed the very
difference is why I decided not to implement them as try/finally.

The thing with try/catch is that the "try-ness" of the first block
*alters* the way that exceptions work inside it. The code of the try
block now has a different meaning; it is effectively a filter on the
kind of result it might yield. Whereas by attaching a FINALLY there is
no difference in meaning, no adjustment.. the FINALLY block is merely a
passive observer of the code having reached a certain position.

> It will be also nice to have conditional exception handling (including
> FINALLY):
> CATCH (connection error) { sleep 10; redo; } if $retry_allowed;

Ambiguous. If the CATCH is conditional, does it make the
exception-filtering properties of its effect on the containing block
conditional as well?

Also, that particular syntax would imply that CATCH blocks now require
a terminating semicolon, otherwise how do we parse

CATCH (thing) { do stuff }

if($cond) { other code }

(that is also the reason for which conditional FINALLY blocks aren't
possible)

> and last but not least: you can easily implement less expressive
> variant (try/catch/finally) using FINALLY / CATCH blocks
>
> Example (pseudo code):
> sub q {
> CATCH (DBI::Connection::Error) { ... }
> my $dbh = connect;
> FINALLY { $dbh->disconnect }
>
> CATCH (no rows selected exception) { return; }
> CATCH (sql exception) { $log->log; redo BLOCK; }
>
> BLOCK:
> $dbh->do (...);
> }

The presence of multiple CATCHes inside a single block now yields
further questions. Do they only take effect from that point onwards,
not covering the lines above? Can they replace each other, or do they
all accumulate and stack up?

These kinds of questions don't apply to FINALLY, because the entire
point is that they stack up. Them all being passive observers of simply
"that block has now finished" means that it's clear what happens when
there's multiple of them. Much less clear to see what multiple CATCHes
with overlapping specifications would mean.


Overall here I really want to appeal to the fact that CPAN already has
*many* many try/catch modules, of which the popular ones appear in
large amounts of other code as dependencies. It seems in this case that
the market has spoken for what it is they want. I don't want to spend
months (or years) inventing new mistakes in core, when we can instead
adopt the tried-and-tested ideas from years of CPAN-based
experimentation. That was always what the `PL_keyword_plugin` mechanism
was for, which has allowed many of these modules in the first place.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/