Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #100396 > unrolled thread

Why is break allowed in finally, but continue is not?

Back to article view | Back to comp.lang.python

Contents

  Why is break allowed in finally, but continue is not? Ned Batchelder <ned@nedbatchelder.com> - 2015-12-13 13:10 -0800
    Re: Why is break allowed in finally, but continue is not? Ben Finney <ben+python@benfinney.id.au> - 2015-12-14 09:27 +1100
      Re: Why is break allowed in finally, but continue is not? Ned Batchelder <ned@nedbatchelder.com> - 2015-12-14 09:37 -0800
        Re: Why is break allowed in finally, but continue is not? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-12-14 18:40 +0000

#100396 — Why is break allowed in finally, but continue is not?

For testing coverage.py, I wrote a program to generate
randomly-structured Python functions.  When compiling
the results, I got a message I'd never seen before:

SyntaxError: 'continue' not supported inside 'finally' clause

I guess this makes sense, when cleaning up from an
exception, continuing the loop seems an odd thing to do.
But 'break' is allowed in 'finally' clauses!  I tried this:

    # Huh? This prints "here", and no exception is raised.

    for i in range(1):
        try:
            1/0
        finally:
            # If you change this to "continue", you get:
            # 'continue' not supported inside 'finally' clause
            break
    print "here"

The finally is perfectly willing to have a 'break', but it's
a syntax error to have 'continue'?  Why? I don't see a
difference between the two when it comes to cleaning up
exceptions.

There are other things you can do in a finally clause that
will prevent the exception from being raised, like 'return',
and 'break' works just fine.

So why treat 'continue' specially?

--Ned.

[toc] | [next] | [standalone]

#100397

Ned Batchelder <ned@nedbatchelder.com> writes:

> For testing coverage.py, I wrote a program to generate
> randomly-structured Python functions.  When compiling
> the results, I got a message I'd never seen before:
>
> SyntaxError: 'continue' not supported inside 'finally' clause
>
> I guess this makes sense, when cleaning up from an
> exception, continuing the loop seems an odd thing to do.
> But 'break' is allowed in 'finally' clauses!  I tried this:
>
>     # Huh? This prints "here", and no exception is raised.
>
>     for i in range(1):
>         try:
>             1/0
>         finally:
>             # If you change this to "continue", you get:
>             # 'continue' not supported inside 'finally' clause
>             break
>     print "here"
>
> The finally is perfectly willing to have a 'break', but it's
> a syntax error to have 'continue'?  Why? I don't see a
> difference between the two when it comes to cleaning up
> exceptions.

Raymond Hettinger's answer is:

    The use of continue in a finally-clause is forbidden because its
    interpretation would have been problematic. […]

    <URL:https://stackoverflow.com/questions/8302293/why-is-continue-not-allowed-in-a-finally-clause-in-python#answer-8302601>

The example he uses::

    for i in range(10):
        print i
        try:
           raise RuntimeError
        finally:
           continue        # if the loop continues, what would happen to the exception?
        print i

What, in your opinion, should the above code do if instead of ‘continue’
some other flow-control statement is used?

> There are other things you can do in a finally clause that
> will prevent the exception from being raised, like 'return',
> and 'break' works just fine.

Hettinger doesn't defend those, and is dubious about ‘return’'s
candidacy:

    Interestingly, you can put a return inside a finally-clause and it
    will swallow all exceptions including KeyboardInterrupt, SystemExit,
    and MemoryError. That probably isn't a good idea either ;-)

> So why treat 'continue' specially?

I am inclined to agree, but in the opposite direction: a case should be
made for allowing *any* flow-control statement in an exception-handler's
‘finally’ clause.

-- 
 \             “We can't depend for the long run on distinguishing one |
  `\         bitstream from another in order to figure out which rules |
_o__)               apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#100416

On Sunday, December 13, 2015 at 5:28:44 PM UTC-5, Ben Finney wrote:
> Ned Batchelder <ned@nedbatchelder.com> writes:
> > So why treat 'continue' specially?
> 
> I am inclined to agree, but in the opposite direction: a case should be
> made for allowing *any* flow-control statement in an exception-handler's
> 'finally' clause.

I agree, those all seem like bad ideas.  But 'continue' has been singled
out for a SyntaxError.  Rumor has it that continue was difficult to make
work at all, while the other keywords, while ill-advised, were at least
possible.

--Ned.

[toc] | [prev] | [next] | [standalone]

#100418

On 14/12/2015 17:37, Ned Batchelder wrote:
> On Sunday, December 13, 2015 at 5:28:44 PM UTC-5, Ben Finney wrote:
>> Ned Batchelder <ned@nedbatchelder.com> writes:
>>> So why treat 'continue' specially?
>>
>> I am inclined to agree, but in the opposite direction: a case should be
>> made for allowing *any* flow-control statement in an exception-handler's
>> 'finally' clause.
>
> I agree, those all seem like bad ideas.  But 'continue' has been singled
> out for a SyntaxError.  Rumor has it that continue was difficult to make
> work at all, while the other keywords, while ill-advised, were at least
> possible.
>
> --Ned.
>

Part of the rumour mill 
http://www.gossamer-threads.com/lists/python/dev/484210?  This was 
referenced from the stackoverflow question that Ben Finney referred to 
yesterday.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web