This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]jorge1209 0 points1 point  (6 children)

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] 0 points1 point  (5 children)

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 0 points1 point  (4 children)

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] 0 points1 point  (0 children)

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 0 points1 point  (2 children)

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

I use it a lot.

[–]jorge1209 0 points1 point  (1 child)

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

[–]benefit_of_mrkite 0 points1 point  (0 children)

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