develooper Front page | perl.perl5.porters | Postings from July 2020

Re: try/catch and CLEANUP/FINALLY/&c.

Thread Previous | Thread Next
From:
=?UTF-8?Q?Branislav_Zahradn=C3=ADk?=
Date:
July 19, 2020 08:31
Subject:
Re: try/catch and CLEANUP/FINALLY/&c.
Message ID:
CAB=rbOkXYAw_v0uKsU9EtPRGyUDPPfT3wXSP2W9kTus0+7GHQA@mail.gmail.com
> Another aspect of CLEANUP is that it has to have access to variables it
> cleans, i.e. it has to share the same lexical scope.
> > For example Java: finally block doesn't see variables declared inside
> try block (omitting AutoCloseable resources) so you have to expose its
> scope into the upper block anyway so usually you'll end up with wrapping
> block anyway.
>
> This aspect seems common to both finally and CLEANUP blocks.
>

CLEANUP block has an access to the scope of the block it cleans. so you
don't need to expose variables into the upper block.


>
> What is the advantage in this case of CLEANUP versus Scope::Guard, though?
> Or of putting the teardown logic in a DESTROY() method (as DBI does anyway)?
>
>
CLEANUP uses strict LIFO whereas Scope::Guard doesn't guarantee execution
order.
There are also additional features planned to define (feature is still
under development), eg:
- how to behave when CLEANUP as executed as a result of an exception and it
raises exception as well
- how to behave when there is a flow control statement (next, last, redo,
return)

You cannot trigger CLEANUP block by "undef $guard"

DESTROY is a method called when object is destroyed, but it doesn't play
well with cycles


> If we’re not catching errors, then yeah, CLEANUP seems reasonable, but in
> that case it’s just adding a core syntax for Scope::Guard. Is that a
> significant enough thing to warrant being its own feature?
>

Considering BEGIN, END, and others, it's consistent with the rest of
language (plus it defines order of execution)


>
> > 3) Given the overwhelming precedent of try/catch/finally, a new Perl
> developer--likely to come from a different language, maybe resentful of
> having to maintain some dot-com-era code rather than “modernizing” it to
> Python--will more likely grasp try/catch/finally at first glance, whereas
> the more esoteric CLEANUP takes extra study.
> >
> > Well, overwhelming doesn't mean right, there was a time when vast
> majority was saying "Sun orbits Earth"
>
> Heliocentrism is a matter of empirical reality. No one can “prove” CLEANUP
> or try/catch/finally; this is mostly just speculation on what people in
> general will consider most useful, a large part of which is an aesthetic
> judgement. In that light, popular taste seems an important consideration.
> If the effort is to make Perl a more attractive language, bucking what’s
> popular seems a strange way to go about it.
>

Off-topic:
I'll disagree with "no one can prove". There is a lot of science around
information, how it is accepted by the human brain, what are limitations of
the human brain, and so.
For example, in real life, every exit is labelled before you pass it -
highway exit, emergency exit, no exit, paid exit.

There are common good practices/suggestions in programming following such
human brain limitations, like "state your intention".

What you call "modern languages" are spin offs of existing languages based
on projects where developers preferred great design over evolution - by
introducing another "great design". There always will be newer, shiny
language, and there always will be C & Perl :-)

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About