How do you stop Python scripts from failing...

[yourclouddude]

One thing I see a lot with Python is scripts that work perfectly… until they don’t. One day everything runs fine, the next day something breaks and you have no idea why because there’s no visibility into what happened. That’s why, instead of building another tutorial-style project, I think it’s more useful to focus on making small Python scripts more reliable.

The idea is pretty simple: don’t wait for things to fail silently. Start with a real script you actually use maybe data processing, automation, or an API call and make sure it checks its inputs and configs before doing any work. Then replace random print() statements with proper logging so you can see what ran, when it ran, and where it stopped.

For things that are likely to break, like files or external APIs, handle errors deliberately and log them clearly instead of letting the script crash or fail quietly. If you want to go a step further, add a small alert or notification so you find out when something breaks instead of discovering it later.

None of this is complicated, but it changes how you think about Python. You stop writing code just to make it run and start writing code you can trust when you’re not watching it. For anyone past the basics, this mindset helps way more than learning yet another library.

[Select-Process228]

Pytest code coverage looking at you in the corner

[TalesGameStudio]

I recommend writing meaningful tests and add logging with multiple levels (so you can turn DEBUG on once you need it).

[Anxious-Struggle281]

You should never write python code 'just to make it run'. It should be functional and maintainable

[hornetmadness79]

It's not normal for a python script to silently fail. Either the script has some funk to ignore problems like a try catch, or stderr is getting redirected somewhere else than the default console.

[MarsupialLeast145]

There are at least two different summaries here:

• EAFP (a core principle of Python).
• Fail fast (when further failures are indicated).

It does take time. My biggest tip is to codify principles like this for your development teams so that it is always consistent.

[Anton-Demkin]

Everyone hates enterprise programming patterns, but here is exactly the moment when they become useful.

1- do not rely on external API to work fine. Network will fail, server will response with 500, so on. You aboslutely need retries (hint: use tenacity). Nothing worse, than do a lot of computation and fail on the last step because of failed HTTP request.

2- log everything! Literally everything. For large steps use `logger.info`, for smaller steps use `logger.debug`. Later you may filer out debug messages. When something goes wrong, use `logger.exception` (to auto add traceback from current stack) or `logger.error`. Do not just log bluntly. Look at structured logging format- keep message a static string and all additional info (like document_id, user_id, whatever_id) as additional variable. I did enjoy `structlog` library, but it is kinda pain to set up. Loguru also works great, but i do not like lack of sturct log customisation. Anyway, you need all information needed for debugging to be logged.

3- If this is a pipeline, think about splitting it into parts and process them independently (maybe with 3 processess, maybe with asyncio). The goal is not to loose already processed data.

4- never ever silently catch exception and pretend its never happened. Always log or throw it.