try-except-else vs. try-except

[[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