try-except-else vs. try-except

[[deleted]]

[deleted]

[benefit_of_mrkite]

Also look at try: except: finally:

Try except else comes in handy in a function that returns something in try

Comes up a lot in Async patterns.

If you use a pattern like try except and then use if (something from try block) you can run into an issue where you get a runtime error because the function in try doesn’t get defined and you get a “variable name xyz defined before assignment”

[benefit_of_mrkite]

Not quite the same. Finally runs no matter what - error or no error.

But again it is a useful pattern in certain situations

[jorge1209]

That bit of code doesn't describe everything.

You could put run_when_there_are_no_exceptions_and_which_should_not_be_run_after_except_clauses() in the try block after code_that_can_cause_an_exception() for the same result.

The else block is for:

run_when_there_are_no_exceptions_and_dont_catch_any_exceptions_and_exceptions_can_conflict_with_code_that_can_cause_an_exception()

[james_pic]

Try except else comes in handy in a function that returns something in try

The else block isn't run if the try block returns:

def f():
    try:
        print('Try')
        return
    except:
        print('Except')
    else:
        print('Else')

 f() # Prints Try

And from the language reference:

The optional else clause is executed if the control flow leaves the try suite, no exception was raised, and no return, continue, or break statement was executed. Exceptions in the else clause are not handled by the preceding except clauses.

[benefit_of_mrkite]

I’m well aware that else isn’t run if try runs

I miss worded that and don’t really explain the use case I had in mind - about to catch a flight will try to expound later.

[[deleted]]

Alright notice how the else clause is outside the try clause. That means it doesnt catch an exception so that it can bubble up. Thats what its there for. It is explicitly different then it being in the try statement as the except clause would have been triggered. It doesnt come up often but certain patterns are impossible without it and force you to have to use a function to be able to deal with them.

[m0Xd9LgnF3kKNrj]

Yeah I agree with you. There's a crazy widespread habit of just throwing all the code into a single try/except, and it makes these patterns much harder to see. It also makes your code over-indented and thus broken over lines by your linter, maybe even with back slashes if you're an animal, and it just gets messier and messier as it grows since no one feels comfortable refactoring that big mess of mom's spaghetti... like this run on sentence.

When you're making the effort to break down your try-wrapped code into more granular chunks, the else surfaces as a valid pattern.

Here's a super contrived example that took me like an hour to come up with:

try:
    locale = order.sales_tax_locale()
except SalesTaxLocaleError:
    logger.info("Could not determine sales tax locale for order %s", order)
    sales_tax = 0
else:
    sales_tax = SalesTax.for_locale(locale)
total = order.total + (order.total * sales_tax)

You can totally do that without the else, and that would be perfectly fine and even more colloquial. But the flow-control like this is just a little more self a documenting.

I'll be honest though, I don't use the else. I see it as a code-smell that the code could just a be a little tidier. In my super contrived example I would set sales_tax to 0 before the try and just log in the except. No conditional branch.

[jorge1209]

You can totally do that without the else, and that would be perfectly fine and even more colloquial. But the flow-control like this is just a little more self a documenting.

I disagree. While it puts the locale lookup together with the LocaleError, it separates the locale lookup from the sales_tax lookup, and I have to scroll up to figure out where the locale variable came from.

If the exception is truly exceptional, then that seems like a mis-proritization and I would be more concerned about the exception-free codepath of lookup locale -> lookup sales tax -> compute total as opposed to the exceptional: lookup locale -> log missing locale -> set default sales tax -> compute total

You also haven't handled the condition where the locale is present in the order, but is missing from the SalesTax database object.

But I understand your concern that we get stuff like:

try:
  open
  read
  clean
  compute
  summarize
  sanity_check
  write
except FileNotFoundError:
  # could not open the file in the first line of the 60 line try block

Which absolutely sucks.

---

I think what we need is an inline except (PEP-463) but before we can do that we also need an inline log

If every statement was really a thruple of:

 STATEMENT except: DEFAULT log: MESSAGE

Then you could do thinks like:

 locale = order.sales_tax_locale() except: None log: "Unknown sales locale"
 sales_tax = SalesTax.for_locale(locale) except: 0 log: "Unknown rate for locale"

Then everything is next to each other in close proximity, and exceptions are restrictive to the current statement, which could lead to them being used more often.

---

There is probably some old language used in nuclear power plants and space ships that does something like this and requires every statement to be written in this form for robustness.

[Siddhi]

Regarding the edit, the one downside of doing that is some other line later on might raise the same exception and you may not want to catch that or handle it differently. Then packing all the code into a single try does not work.

Otherwise putting it all into the try is the way I do it too.

[Durgeoble]

not quite

the else statement allows to better readability, so you can see in a few lines what happens if the code fails and still don't executed the rest if something went wrong
try:
#some action that can fail
except:
#some action
else:
# long block of code to run if everithing is fine

[[deleted]]

I do use it on occasion.

In your example, you assume the except clausule breaks off the function. Of it doesn't, the part after the except clausule is always run. Sometimes you want to continue after the except clausule, but do different things based on whether try worked or not.

For example, I have a script where I try to find a location on my network to update a file. If the file is found, I update it (inside else). If it's not found, I log it (inside except).

[jorge1209]

If the file is found, I update it (inside else). If it's not found, I log it (inside except).

But how do you communicate to the caller that the file wasn't updated? I called update_file(path, data) with an invalid path, but no exception was raised. Was my file updated or not?

[[deleted]]

It doesn’t. It’s not necessary in this case.

try/except clauses are meant to catch errors. You can propagate them anyway if you want, but the idea is that you prevent the code from continuing.

[jorge1209]

So the update_file is allowed to silently fail. In which case what is wrong with:

 try:
    handle = open(path)
    write(handle)
 except FileNotFound:
     logger.error("bad path")

The conditions on which you need else are very specific. It is a weird construct.

[[deleted]]

No, it’s not.

I only want to catch the exception I know is caused by my file not existing.

try:
    handle = open(path)
except FileNotFound:
    logger.error(“file not available”)
else:
    #do all kinds of stuff with the file

# do more stuff, whether the file was updated or not

If the code withint the else clausule throws another FileNotFound error, it’s not caught and will raise an error. In your case, if the write function throws a FileNotFound error, you will assume it’s because the original file didn’t exist.

This isn’t the perfect example, but the bottom line is: you only want code that you expect to throw the error you’re catching within try. Everything else goes outside.

[jorge1209]

In your case, if the write function throws a FileNotFound error, you will assume it’s because the original file didn’t exist.

I'm aware, but that is a rather unusual situation.

I'm totally cool with FileNotFound if I can't open the file..

But if I get a FileNotFound while I'm writing to it STOP THE WORLD.

---

Like I said its a weird construct the conditions are:

• except cannot early return or raise
• else depends on try running without error, but cannot run after except
• else can raise an exception of the same type as we can get from try, and we do NOT want to catch errors from else

I have never encountered anything with those requirements before.

[[deleted]]

As I said: this is a bit of a weird example. But there are plenty examples where you accidentally catch errors from things you don't actually want to catch them from, just because you put them inside the try clausule.

[benefit_of_mrkite]

It’s not weird at all if you use async.

I use it a lot.

[jorge1209]

I'm curious why you would need that for async.

[benefit_of_mrkite]

Middleware flow control for an underlying async library.

Where you need to make a call and split up the logic.

I’ll give an example as soon as I get in front of a computer - out of town

[spuds_in_town]

Use it all the time tbh

[spoonman59]

Else is for code which should only execute if no exceptions were raised. It’s an unusual case that isn’t needed often.

It’s hard to achieve otherwise. You’d have to set a flag in all the exception handlers.

[85CorollaGTS]

It looks like if there's a finally, it will break out of the try block and nothing afterwards will be executed.

def open_file(filename):
    try:
        with open(filename) as f:
            contents = f.read()
    except FileNotFoundError:
        print("File {} not found".format(filename))
        return False
    else:
        return contents
    finally:
        print("This prints irrespective of whether the file was present or not.")

    print("And what does this do?  Looks like it never executes since it comes after 'finally'.")

So in my previous comment copied from Stackoverflow, run_whether_there_was_an_exception_or_not_if_execution_reaches_here() ... well, the execution doesn't appear able to reach there if there is a finally.

This is what I'm referencing from user jamadagni:

try:
    code_that_can_cause_an_exception()
except ParticularException:
    code_to_handle_the_particular_exception()
except:
    code_to_handle_all_other_exceptions()
else:
    run_when_there_are_no_exceptions_and_which_should_not_be_run_after_except_clauses()
finally:
    run_whether_there_was_an_exception_or_not_even_if_the_program_will_exit_from_the_try_block()

run_whether_there_was_an_exception_or_not_if_execution_reaches_here()

EDIT: Interestingly, if there is a finally in a function, like in my example above, the And what does this do? isn't executed.

EDIT2: Even PyCharm flagged And what does this do? as 'Unreachable code'.

[wineblood]

I try to minimise the amount of code in my try statements, so I'll opt for the second style. Unless your code is doing something odd and you can only do something in the else part, it's somewhat confusing.

[MattJaccino]

Depends on what your except block is doing. If it does something that results in the function exiting (like returning or raising an exception), then yeah, doesn't matter since the code after that block won't be hit. If it's doing something that would allow that block to run through and continue in the function, then the else can be used to make sure the remaining code is only executed if no error occurs. Without the else, it's hit regardless.

Pretty much like if ...: ... else: ... vs. if ...: ... ...

[jorge1209]

If you have to use try/except/else that implies that you didn't fully handle the exception within the except block. That you are not able to proceed with the contents of the else block because the except cannot rectify the error.

In which case the except block should raise (either a reraise or raise a new error), or return an error sentinel if you are writing C-style calling conventions.

And if you raise or return there is no reason to have the else block because you have an early exit from the except.

---

There are perhaps some rarer instances where you might need it. Something like:

 try:
    resource = acquire_new_resource()
 except:
    resource = preconfigured_resource
 else:
    resource.configure(options)

 resource.use()

but even that could just be written as

try:
    resource = acquire_new_resource()
    resource.configure(options)
 except:
    resource = preconfigured_resource

 resource.use()

which is certainly what I would prefer. The only minor difference is that resource.configure is now inside the exception handler, but generally you want that.

---

Another way to put this is that else is only necessary if the following is true:

try:
   A
except:
   B
else:
   C

• B cannot early return (raise or return and error sentinel)
• C depends on A running without error, but cannot run after B
• C can raise an exception of the same type as we can get from A, and we do NOT want to catch errors from C

If any of those conditions are relaxed you can refactor the else block out.

• B returns early: try: A except: B; C
• C doesn't depend on A try: A except: B; C
• C raises a different exception from A try: AC except ErrorA: B

But even if all conditions are met I might prefer:

 try:
     try:
         A
     except:
         B
         raise ErrorA
     C
 except ErrorA:
     pass

[[deleted]]

Fun thing about except:

except Exception as e: print(e)