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

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

try/except/finally

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

Contents

  try/except/finally Frank B <fbicknel@gmail.com> - 2014-06-06 10:30 -0700
    Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-06 13:39 -0400
      Re: try/except/finally Frank B <fbicknel@gmail.com> - 2014-06-06 10:47 -0700
        Re: try/except/finally Ned Batchelder <ned@nedbatchelder.com> - 2014-06-06 14:22 -0400
        Re: try/except/finally Ethan Furman <ethan@stoneleaf.us> - 2014-06-07 15:49 -0700
        Re: try/except/finally Chris Angelico <rosuav@gmail.com> - 2014-06-08 09:47 +1000
          Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-07 20:12 -0400
            Re: try/except/finally Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-08 02:10 +0100
              Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-07 21:32 -0400
              Re: try/except/finally Marko Rauhamaa <marko@pacujo.net> - 2014-06-08 10:12 +0300
                Re: try/except/finally Joshua Landau <joshua@landau.ws> - 2014-06-08 18:57 +0100
                Re: try/except/finally Ian Kelly <ian.g.kelly@gmail.com> - 2014-06-08 12:07 -0600
                Re: try/except/finally Ian Kelly <ian.g.kelly@gmail.com> - 2014-06-08 12:02 -0600
          Re: try/except/finally Rustom Mody <rustompmody@gmail.com> - 2014-06-07 20:58 -0700
            Re: try/except/finally Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2014-06-10 09:27 +0200
              Re: try/except/finally Marko Rauhamaa <marko@pacujo.net> - 2014-06-10 12:07 +0300
              Re: try/except/finally Rustom Mody <rustompmody@gmail.com> - 2014-06-10 05:06 -0700
                Re: try/except/finally Skip Montanaro <skip@pobox.com> - 2014-06-10 13:11 -0500
                  Re: try/except/finally Rustom Mody <rustompmody@gmail.com> - 2014-06-10 19:01 -0700
              Re: try/except/finally Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-10 19:14 +0100
                Re: try/except/finally Grant Edwards <invalid@invalid.invalid> - 2014-06-10 18:48 +0000
                  Re: try/except/finally Chris Angelico <rosuav@gmail.com> - 2014-06-11 06:37 +1000
                    Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-10 16:38 -0400
                      Re: try/except/finally Chris Angelico <rosuav@gmail.com> - 2014-06-11 06:43 +1000
                      Re: try/except/finally Ethan Furman <ethan@stoneleaf.us> - 2014-06-10 13:43 -0700
                      Re: try/except/finally Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-10 22:59 +0100
                    Re: try/except/finally Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-11 00:00 +0000
                      Re: try/except/finally Chris Angelico <rosuav@gmail.com> - 2014-06-11 10:12 +1000
                        Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-10 20:22 -0400
                      Re: try/except/finally Tim Delaney <timothy.c.delaney@gmail.com> - 2014-06-11 10:40 +1000
                      Re: try/except/finally Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-11 01:53 +0100
                      Re: try/except/finally Chris Angelico <rosuav@gmail.com> - 2014-06-11 11:00 +1000
                      Re: try/except/finally Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-11 02:06 +0100
                      Re: try/except/finally alister <alister.nospam.ware@ntlworld.com> - 2014-06-11 08:35 +0000
                        Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-11 08:50 -0400
                Re: try/except/finally alister <alister.nospam.ware@ntlworld.com> - 2014-06-10 19:02 +0000
      Re: try/except/finally Joshua Landau <joshua@landau.ws> - 2014-06-08 19:05 +0100
    Re:try/except/finally Dave Angel <davea@davea.name> - 2014-06-07 21:59 -0500
      Re: try/except/finally Philip Shaw <jnufcvyvuc@tznvy.pbz> - 2014-06-09 09:13 +0000
        Re: try/except/finally Marko Rauhamaa <marko@pacujo.net> - 2014-06-09 12:40 +0300
          Re: try/except/finally Shiyao Ma <i@introo.me> - 2014-06-10 00:23 +0800
          Re: try/except/finally Skip Montanaro <skip@pobox.com> - 2014-06-09 11:56 -0500

Page 1 of 3  [1] 2 3  Next page →

#72872 — try/except/finally

Ok; this is a bit esoteric.

So finally is executed regardless of whether an exception occurs, so states the docs.

But, I thought, if I <return> from my function first, that should take precedence.

au contraire

Turns out that if you do this:

try:
  failingthing()
except FailException:
  return 0
finally:
  return 1

Then finally really is executed regardless... even though you told it to return.

That seems odd to me.

[toc] | [next] | [standalone]

#72874

In article <0a89c96d-de62-42ad-be48-6107ce10d215@googlegroups.com>,
 Frank B <fbicknel@gmail.com> wrote:

> Ok; this is a bit esoteric.
> 
> So finally is executed regardless of whether an exception occurs, so states 
> the docs.
> 
> But, I thought, if I <return> from my function first, that should take 
> precedence.
> 
> au contraire
> 
> Turns out that if you do this:
> 
> try:
>   failingthing()
> except FailException:
>   return 0
> finally:
>   return 1
> 
> Then finally really is executed regardless... even though you told it to 
> return.
> 
> That seems odd to me.

That's exactly what it's supposed to do.  The idea of finally is, "No 
matter what else happens, including calling sys.exit(), make sure this 
code executed".  It's typically used to release some critical resource 
which was acquired in the body of the try block.
 
https://docs.python.org/2/reference/compound_stmts.html#the-try-statement
 says:

When a return, break or continue statement is executed in the try suite 
of a try...finally statement, the finally clause is also executed Śon 
the way out.ą

The only way I can think of to bypass a finally block would be to call 
os._exit(), or send yourself a kill signal.

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

#72875

Ok; thanks for the underscore and clarification.  Just need to adjust my thinking a bit.

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

#72879

On 6/6/14 1:47 PM, Frank B wrote:
> Ok; thanks for the underscore and clarification.  Just need to adjust my thinking a bit.
>

Did this come up in real code?  I've seen this point about 
finally/return semantics a number of times, but haven't seen real code 
that needed adjusting based on it.

-- 
Ned Batchelder, http://nedbatchelder.com

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

#72936

On 06/06/2014 11:22 AM, Ned Batchelder wrote:
> On 6/6/14 1:47 PM, Frank B wrote:
>>
>> Ok; thanks for the underscore and clarification.  Just need to adjust my thinking a bit.
>
> Did this come up in real code?  I've seen this point about finally/return semantics a number of times, but haven't seen
> real code that needed adjusting based on it.

I don't remember if I almost had this in real code or if I learned about it first, but it can definitely be a gotcha. 
It seems to me that if the try block exits with an explicit return, and then the finally block exits with an explicit 
return, some kind of error ought to be raised.

--
~Ethan~

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

#72938

On Sun, Jun 8, 2014 at 8:49 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
> I don't remember if I almost had this in real code or if I learned about it
> first, but it can definitely be a gotcha. It seems to me that if the try
> block exits with an explicit return, and then the finally block exits with
> an explicit return, some kind of error ought to be raised.

I'd go a little simpler: A return statement inside a finally block is
code smell.

ChrisA

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

#72940

In article <mailman.10867.1402184850.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> A return statement inside a finally block is code smell.

Not to my nose.  It seems like a perfectly reasonable thing to do.

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

#72945

On 08/06/2014 01:12, Roy Smith wrote:
> In article <mailman.10867.1402184850.18130.python-list@python.org>,
>   Chris Angelico <rosuav@gmail.com> wrote:
>
>> A return statement inside a finally block is code smell.
>
> Not to my nose.  It seems like a perfectly reasonable thing to do.
>

I agree, the code smell is the return in the except block.

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

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

#72948

In article <mailman.10871.1402189805.18130.python-list@python.org>,
 Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:

> On 08/06/2014 01:12, Roy Smith wrote:
> > In article <mailman.10867.1402184850.18130.python-list@python.org>,
> >   Chris Angelico <rosuav@gmail.com> wrote:
> >
> >> A return statement inside a finally block is code smell.
> >
> > Not to my nose.  It seems like a perfectly reasonable thing to do.
> >
> 
> I agree, the code smell is the return in the except block.

That's not setting my nose on end either.

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

#72956

Mark Lawrence <breamoreboy@yahoo.co.uk>:

>>> A return statement inside a finally block is code smell.
>> Not to my nose.  It seems like a perfectly reasonable thing to do.
> I agree, the code smell is the return in the except block.

Here's a regular pattern that I use for nonblocking I/O:

    def poll(self):
        try:
            message = self.sock.recv(0x10000)
        except IOError as e:
            if e.errno == errno.EAGAIN:
                return
            if errcode == errno.EINTR:
                self.trigger()
                return
            self.handle_io_error(e.errno)
            return
        self.trigger()
        self.handle_recv(message)

Does anyone have an example motivating a return from finally? It seems
to me it would always be a bad idea as it silently clears all unexpected
exceptions.


Marko

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

#72983

On 8 June 2014 08:12, Marko Rauhamaa <marko@pacujo.net> wrote:
>
> Does anyone have an example motivating a return from finally? It seems
> to me it would always be a bad idea as it silently clears all unexpected
> exceptions.

In a general sense:

    try:
        something_that_can_break()
        return foo() # before clean_up
    finally:
        clean_up()
        if default:
            return default() # after clean_up()

What's the best replacement? Note: I've never done this.

---

I do sometimes use

    try:
        return x
    finally:
        x += 1

over

    ret = x
    x += 1
    return ret

now-a-days.

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

#72986

On Sun, Jun 8, 2014 at 12:02 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Sun, Jun 8, 2014 at 11:57 AM, Joshua Landau <joshua@landau.ws> wrote:
>> On 8 June 2014 08:12, Marko Rauhamaa <marko@pacujo.net> wrote:
>>>
>>> Does anyone have an example motivating a return from finally? It seems
>>> to me it would always be a bad idea as it silently clears all unexpected
>>> exceptions.
>>
>> In a general sense:
>>
>>     try:
>>         something_that_can_break()
>>         return foo() # before clean_up
>>     finally:
>>         clean_up()
>>         if default:
>>             return default() # after clean_up()
>>
>> What's the best replacement? Note: I've never done this.
>
> Why not just move the default out of the finally block?
>
>     try:
>         something_that_can_break()
>         return foo() # before clean_up
>     finally:
>         clean_up()
>     if default:
>         return default() # after clean_up()

Never mind, that doesn't work.  But you could do this:

    try:
        something_that_can_break()
        return foo() # before clean_up
    except ExpectedException:
        if default:
            return default() # after clean_up()
        else:
            raise
    finally:
        clean_up()

And then anything unexpected will be propagated instead of silenced.

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

#72988

On Sun, Jun 8, 2014 at 11:57 AM, Joshua Landau <joshua@landau.ws> wrote:
> On 8 June 2014 08:12, Marko Rauhamaa <marko@pacujo.net> wrote:
>>
>> Does anyone have an example motivating a return from finally? It seems
>> to me it would always be a bad idea as it silently clears all unexpected
>> exceptions.
>
> In a general sense:
>
>     try:
>         something_that_can_break()
>         return foo() # before clean_up
>     finally:
>         clean_up()
>         if default:
>             return default() # after clean_up()
>
> What's the best replacement? Note: I've never done this.

Why not just move the default out of the finally block?

    try:
        something_that_can_break()
        return foo() # before clean_up
    finally:
        clean_up()
    if default:
        return default() # after clean_up()

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

#72952

On Sunday, June 8, 2014 5:17:21 AM UTC+5:30, Chris Angelico wrote:
> On Sun, Jun 8, 2014 at 8:49 AM, Ethan Furman  wrote:
> > I don't remember if I almost had this in real code or if I learned about it
> > first, but it can definitely be a gotcha. It seems to me that if the try
> > block exits with an explicit return, and then the finally block exits with
> > an explicit return, some kind of error ought to be raised.

> I'd go a little simpler: A return statement inside a finally block is
> code smell.

Some people¹ think that gotos are a code-smell.

And since both return and exceptions are thinly veiled gotos, what we
have here are two smells outsmelling each other.

¹ I am not exactly those people.
A chap called E W Dijkstra made the statement: "Goto statement considered 
harmful" and became famous.
The chap who taught me programming said to me: "What the goto does to 
control structure, the assignment does to data structure"
He did not become famous.
However in my view he made the more intelligent statement

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

#73075

Am 08.06.2014 05:58 schrieb Rustom Mody:

> Some people¹ think that gotos are a code-smell.
>  ¹ I am not exactly those people.
> A chap called E W Dijkstra made the statement: "Goto statement considered
> harmful" and became famous.

And became widely misunderstood. If anybody would read the whole what he 
wrote, people would learn that he doesn't criticise the *use* of goto, 
but he wants the *replacement* of goto with something else (like 
exceptions).

As C doesn't have exceptions, goto is in many cases the simplest and 
easiest way of handling errors.

Essentially, you can write both good and bad code both with and without 
goto.


Thomaas

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

#73078

Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de>:

> Essentially, you can write both good and bad code both with and
> without goto.

Point is, choose tasteful idioms in your code.


Marko

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

#73085

On Tuesday, June 10, 2014 12:57:29 PM UTC+5:30, Thomas Rachel wrote:
> Am 08.06.2014 05:58 schrieb Rustom Mody:

> > Some people� think that gotos are a code-smell.
> >  � I am not exactly those people.
> > A chap called E W Dijkstra made the statement: "Goto statement considered
> > harmful" and became famous.

> And became widely misunderstood. If anybody would read the whole what he 
> wrote, people would learn that he doesn't criticise the *use* of goto, 
> but he wants the *replacement* of goto with something else (like 
> exceptions).

> As C doesn't have exceptions, goto is in many cases the simplest and 
> easiest way of handling errors.

> Essentially, you can write both good and bad code both with and without 
> goto.

Here is Dijkstra:
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

First statement:
| For a number of years I have been familiar with the observation that
| the quality of programmers is a decreasing function of the density of
| go to statements in the programs they produce.

And here is Hoare, not identical to Dijkstra but with similar areas of 
interest and similar views on correctness etc, very unambiguously
criticising exceptions:

| Ada has a plethora of features and notational conventions, many of them
| unnecessary and some of them, like exception handling, even
| dangerous.  Do not allow this language in its present state to be
| used in applications where reliability is critical

http://en.wikipedia.org/wiki/Exception_handling#Criticism

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

#73111

> Here is Dijkstra:
> http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html
...
> And here is Hoare...

> | Ada has a plethora of features and notational conventions, many of them
> | unnecessary and some of them, like exception handling, even
> | dangerous.  Do not allow this language in its present state to be
> | used in applications where reliability is critical.

Would be interesting to get their collective take on C++...

Are there any good parts? It appears the book was cancelled (note the
remarks):

https://www.matthewsbooks.com/productdetail.aspx?productid=4493SAT1969&returnurl=%2Fforthcomingtitles.aspx%3Fsort%3D0%26images%3D1%26print%3Dtrue

Skip

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

#73151

On Tuesday, June 10, 2014 11:41:45 PM UTC+5:30, Skip Montanaro wrote:
> Would be interesting to get their collective take on C++...

> Are there any good parts? It appears the book was cancelled

> https://www.matthewsbooks.com/productdetail.aspx?productid=4493SAT1969&returnurl=%2Fforthcomingtitles.aspx%3Fsort%3D0%26images%3D1%26print%3Dtrue

> (note the remarks):

And — if ‘i’≡‘y’ — the author.

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

#73112

On 10/06/2014 08:27, Thomas Rachel wrote:
> Am 08.06.2014 05:58 schrieb Rustom Mody:
>
>> Some people¹ think that gotos are a code-smell.
>>  ¹ I am not exactly those people.
>> A chap called E W Dijkstra made the statement: "Goto statement considered
>> harmful" and became famous.
>
> And became widely misunderstood. If anybody would read the whole what he
> wrote, people would learn that he doesn't criticise the *use* of goto,
> but he wants the *replacement* of goto with something else (like
> exceptions).
>
> As C doesn't have exceptions, goto is in many cases the simplest and
> easiest way of handling errors.
>
> Essentially, you can write both good and bad code both with and without
> goto.
>
> Thomaas

I entirely agree.  I find it incredible that some people find it so 
difficult to differentiate having tens or even hundreds of gotos leaping 
around willy nilly to a similar number of labels, and a similar number 
of gotos targetted at one label called SNAFU or whatever.

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

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web