Shulou(Shulou.com)06/02 Report--

This article will explain in detail what is the seven-step method of catching insects in Python. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Know some techniques to help you reduce the time it takes to check for errors in your code.

At 03:00 on Friday afternoon (why this time? Because it always happens at 03:00 on Friday afternoon.) you receive a notification and the customer finds an error in your software. After having initial doubts, you contact the operation and maintenance staff to check your software log to find out what happened, because you remember receiving a notice that the log has moved.

As a result, these logs have been transferred to places you can't get, but they are being imported into a web app-so you can use this beautiful app to retrieve the logs, but the application is not finished yet. The application is expected to be completed in a few days. I know, you think it's totally impractical. However, no, logs or log messages often seem to disappear at the wrong time. Before we start checking for errors, a piece of advice: always check your logs to make sure they are where you think they should be, and record what you think they should remember. These things tend to change surprisingly when you're not paying attention.

Well, you found the log or tried to call the operator, and the customer did find an error. You may even think you already know where the mistake is.

You immediately open the file that you think may be problematic and begin to check for errors.

1. Don't touch your code yet

If you read the code, you may even think about which parts to read. But before you start messing up your code, reproduce the call that caused the error and turn it into a test. This will be an integration test, because you may have other questions, and you don't know exactly what the problem is yet.

Make sure the test results fail. This is important because sometimes your tests cannot reproduce failed calls, especially if you use web or other frameworks that confuse tests. A lot of things may be stored in variables, but unfortunately, just by observing the test, what you call in the test is not always obvious. When I try to reproduce the failed call, I'm not saying I'm going to create a test that passes, but, well, I did create a test, but I don't think it's particularly unusual.

Learn from your mistakes.

2. Write the wrong test

Now that you have a failed test, or maybe a test with an error, it's time to solve the problem. But before you do it, let's check the call stack because it makes it easier to solve the problem.

The call stack includes all tasks that you have started but have not yet completed. So, for example, if you are baking a cake and are ready to add flour to the batter, your call stack will be:

Make a cake

Batter

Add flour

You've started making cakes, you've started battering, and you're adding flour now. Putting oil on the bottom of the pan is not on this list because you have done it, and frosting is not on this list because you haven't started yet.

If you are not clear about the call stack, I strongly recommend that you use Python Tutor, which helps you observe the call stack as you execute the code.

Now, if something goes wrong with your Python program, the Python interpreter will print out the current call stack for you. This means that no matter what the program is doing at that moment, it is obvious that the error occurs at the bottom of the call stack.

3. Always check the bottom of the call stack first

Not only can you see which error occurred at the bottom of the stack, but you can usually find the problem on the * line of the call stack. If the bottom of the stack is not helpful to you and your code has not been analyzed yet, then using code analysis is very useful. I recommend pylint or flake8. Usually, it points out the mistakes I've been ignoring.

If the error looks confusing, your next step may be to search it with Google. If you search for content that does not contain information about your code, such as variable names, files, etc., you will get better search results. If you are using Python 3 (which you should use), it is helpful to search for content that includes Python 3, otherwise Python 2 solutions tend to be in the majority.

A long time ago, developers needed to solve problems without the help of search engines. It was a dark time. Make full use of all the tools you can use.

Unfortunately, sometimes the problem occurs at an earlier stage, but only where it is executed at the bottom of the call stack. It's like forgetting to add baking powder when the cake doesn't swell.

Then you should check the entire call stack. The problem is more likely to be in your code than in Python standard libraries or third-party packages, so check your code in the call stack first. In addition, it is usually easier to check your code by placing breakpoints in your code. Place a breakpoint in the code of the call stack and see if it is as you expected.

"but, Mary," I heard you say, "if I had a call stack, all this would help, but I only had one failed test. Where should I start?"

Pdb, a Python debugger.

Find the place in your code that will be called by this. You should be able to find at least one such place. Make a breakpoint for pdb there.

A digression

Why not use the print statement? I used to rely on print statements. Sometimes, they are still very convenient. But when I started dealing with complex code bases, especially those with network calls, print statements became too slow. I ended up adding print statements everywhere, but I couldn't track their location and why, and it got more complicated. But there is a more important reason for mainly using pdb. Suppose you add a print statement to find the error problem, and the print statement must be earlier than where the error occurred. However, if you look at the function where you put the print statement, you don't know how your code gets to that location. Looking at the code is a good way to find the call path, but it's scary to look at the code you've written before. Yes, I use grep to process my code base to find a place to call a function, but this becomes tedious, and searching for a generic function does not narrow the search. Pdb becomes very useful.

You follow my advice, hit the pdb breakpoint and run your test. However, the test failed again, but none of the breakpoints were *. Keep your breakpoint and run a test in the test suite that is very similar to the failed test. If you have a good test suite, you should be able to find one. It will * the code that you think your failed test should *. Run the test, and then when it reaches your breakpoint, press w and check the call stack. If you don't know how to view the call stack that is messed up by other calls, find your code in the middle of the call stack and place a breakpoint on the previous line of code in the stack. Try a new test again. If there is still no breakpoint, go ahead, trace the call stack up and find out where your call was derailed. If you haven't had a breakpoint and reached the top of the trace, congratulations, you've found a problem: your application name is misspelled.

No experience, rookie, no experience at all.

4. Modify the code

If you're still confused, try a new test where you've changed a little bit. Can you get the new test running? What's the difference? What is the same? Try to change something else. When you have your tests, and possibly other tests, you can start to safely modify the code to determine if you can narrow the problem. Remember to start with a new submission so that invalid changes can be easily undone. This is version control, and if you haven't used it, it will change your life. Well, maybe it just makes coding easier. Check out the version Control Visual Guide to learn more. )

5. Have a rest

Still, when it no longer feels like an interesting challenge or game and starts to get frustrating, your move is to get out of the problem. Taking a nap. I strongly suggest you go for a walk and try to think about something else.

6. Write everything down

When you come back, if you are not suddenly inspired, write down every bit of information you know about the problem. This should include:

The call that really caused the problem

What really happened, including any error messages or related log information

What do you really expect to happen?

What have you done so far to find out the problem; and any clues you have found in solving the problem.

Sometimes there's a lot of information here, but believe me, it's annoying to dig up information from bits and pieces. So try to be concise, but complete.

7. Seek help

I often find that writing down all the information inspires me to think of things I haven't tried yet. Of course, sometimes I realize what the problem is as soon as I click the submit button on the help email (or form). In any case, when you still find nothing after writing down everything, try emailing someone else for help. First, your colleagues or other people involved in your project, and then the mailing list of the project. Don't be afraid to ask for help. Most people are friendly and helpful, especially in the Python community.

About what is the Python seven-step method to catch insects to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.