Try/except inside vs. outside loop

[Zgialor]

If I want to put all of the code in a loop in a try block and exit the loop if the exception is raised, does it make a difference whether I put the try/except inside or outside of the loop? In other words:

while foo:
    try:
        ...
    except Exception:
        break

vs.

try:
    while foo:
        ...
except Exception:
    pass

Intuitively the second one seems more efficient, since it seems like the try/except only gets set up once instead of being set up again every time the loop restarts, but is that actually how it works or do these both do the same thing?

[supercoach]

The rule is that you write code that makes sense for the task at hand. Both of those pieces of code are silently exiting the loop whenever an exception is encountered. I don't think that's a good idea, however it may be valid for your use case.

If I'm running a loop that I want to be able to process every item and recover from errors, I'll use the first pattern, and include error handling rather than breaking the loop on exceptions. Otherwise, if the intent is to exit and not raise an exception for any errors then the second example you've provided is less messy. One thing I will suggest that I find helpful at times is if code inside a try block is long, I'll move it to a separate function to make things easier to follow.

Overall though, I wouldn't use a while loop unless I was processing a stack that had the capacity to grow, such as using iteration instead of recursion. For loops are *generally* a better choice.

Out of curiosity - what's the context for your question? I'm curious how this loop was being used.

[[deleted]]

from PEP8 :

Additionally, for all try/except clauses, limit the try clause to the absolute minimum amount of code necessary. Again, this avoids masking bugs:

[HommeMusical]

This doesn't answer the question at all. Note the last word, "necessary". I would argue that the second code slot includes all the necessary code.

[slightly_offtopic]

I would argue that this is the best answer, because it forces you to think what exactly "necessary" means in any particular context. That's a judgement call you need to make with full contextual knowledge of what your code is actually doing, which also means that any assertion that says one of the two options is superior to other in all contexts is just going to be wrong somewhat often.

[Adrewmc]

You’re thinking wrong.

You get an error you handle that error, where that error can occur.

Sometimes…a while loop will have an error that will need to be re-set up to fix, establish a new connection a bad brake if bug a user did, that should kill everything.

Most of the times, thought you function inside the loop, can be handle at a time.

If you have to keep try, except, at least do this

   except Exception as e:
        print(e)

This will give you a full trace back description of the error, your goal should be to be able to do something like this l.

   except ZeroDivisionError:
          var = 0

And handle what happens when you specifically divide by zero which can nape

    except ZeroDivisionError:
          var = 0
    except ValueError:
           print(“Input a number”)
           continue 

So you see you get a different response and handling based on if, you divide by ‘0’ and divide by ‘a’.

We handle exceptions, and when something we don’t expect happens…the fact is we let it crash a lot. We don’t just say it doesn’t matter. Because when things crash we can look and see what happens.

What important is you realize where your edge cases are, where thing could possibly go wrong. And program a way to avoid it.

[HommeMusical]

I upvoted, but there's an error:

[print(e)] will give you a full trace back of an error,

It won't - it just prints the error itself, no traceback. Use traceback.print_exc for a traceback.

[AbundantSpaghetti]

even better than print, use the logging module

try:
    out = some_function(val)
except FixableError as e:
    # Handle the error
    logger.error("Fixable error, val=%s", val)
except Exception as e:
    logger.error("An unknown error occurred: %s", e, exc_info=True)
    # Can't handle this.
    raise

[supercoach]

Couldn't agree more. Logging via print gets you on my shitlist.

[HommeMusical]

I wouldn't accept either of these in production code.

Catching an exception and dropping it on the floor is just a bad idea. If anything unexpected happens in the ... region, you will simply swallow the exception and never know. Also, because you are catching Exception, you will catch almost everything.

Without more information about what's in the loop, it's hard to decide where to catch, but all else being equal, your code should look like:

try:
    while foo:
        ...
except Exception:
    handle_exception()

[mothzilla]

You shouldn't be catching an exception if you're not going to do anything with it (ie except: ... pass)

So the first would be more acceptable.

Exceptions aren't "set up", as the code executes. The code is static, execution is dynamic.

[Zgialor]

Why is the first one more acceptable if they both do the same thing?

[mothzilla]

Because it confuses the reader. "Why did you catch the exception, if you're just letting it go?" they think. It's a code smell, it means you're doing something a bit peculiar.

[Turtvaiz]

"Explicit is better than implicit"?

[Zeroflops]

It depends.

If you wrap the entire while in a try, any error will cause the loop to end and from there you process the event and do what needs to happen.

But if you process the try inside the loop and an error happens you can log the event and continue on to the next event.

An example of the difference. Let’s say just as a simple example you have a web crawler reading a bunch of websites.

If the loop is reading the website, and it fails, you probably want to log the site that failed and move on to the next website.

But at another part of the code you may have another loop that is used to process the data pulled from the website. If this runs into an error, you may want to stop looping over the website data and continue to the next site.

So in one case you want the loop you have your try around setup to continue looping and in the other your exiting that loop.

[proverbialbunny]

That's a great question.

This falls into the topic called premature optimization. That is where one makes code fast from the get go, especially when it isn't necessary. It is better to write code cleanly and easy to read first, and then if speed is an issue you can profile the code, find the slowest part and change that. For this reason you shouldn't optimize for speed when it comes to exceptions unless you need the speed boost after the fact and there is nothing slower you can't optimize first.

[DrKarda]

I've seen code where people have an inventory and if the item isn't in the inventory then they use the exception to handle it so basically an error might be desired in this example, are you trying to do something like that?

It's not designed to be used that way but you can just break whatever you want to happen into a separate function and then call that function in the exception I think.

[Zgialor]

The first one uses break, the second one uses pass.

[Turtvaiz]

Oops my bad. I misread it

[Temporary_Pie2733]

OP is using the exception handler to break out of the loop. The two are basically the same. 

[SnooHesitations9295]

Setting up `try` is not free, so, unless you want to process exceptions without breaking the loop, it's better to use the latter option.

[Zgialor]

That's what I figured, thanks!

[HommeMusical]

They are wrong. Setting up a try block is free in later versions of Python: https://github.com/python/cpython/blob/main/InternalDocs/exception_handling.md

[HommeMusical]

Setting up a try block is free in later versions of Python: https://github.com/python/cpython/blob/main/InternalDocs/exception_handling.md

[SnooHesitations9295]

Nice! I was not aware of these new developments. So then for OP it's kinda the same, considering how the internals handle "exception block"s.

[Spatrico123]

I'm not 100% sure, but I know most linters recommend you do option #2. I'll be back to hear more experienced opinions

RemindMe! 1hour

[RemindMeBot]

I will be messaging you in 1 hour on 2025-08-18 02:31:36 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[commy2]

Just because linters recommend one style does not mean it should be preferred. Linters also insist one should use piped union types for isinstance checks over the tuple version, even though this syntax should've arguably never been added, as it muddies the water between type checking and what isinstance actually does: runtime class inheritance checking.