Part 1:
Python Console:
Flowchart:
Python Console:
Part 3:
Flowchart:
Python Console:
Flowchart Part B:
Searching for errors in the script was very good practice for me this week. I am learning to read script a little better, and being able to find syntax, attribute, and name errors in the script made me feel more confident with what I’m learning. Errors can be so easy to make, from letter case to typos. The run tool is not very helpful if you have an error in your script, so it was good to learn how to use the Debugging tool to take everything line by line. I think for practice this helped me as well. When I’m reading the script in the editor pane, my eyes jump around, and I try to pinpoint errors anywhere and everywhere. Using the debugging tool helped me review the script line by line, and fix errors line by line so I can tell which editing attempts work and which did not. I think the debugging tool will help me learn to be more organized in my script editing if nothing else.
Flowchart Part A:
Searching for errors in the script was very good practice for me this week. I am learning to read script a little better, and being able to find syntax, attribute, and name errors in the script made me feel more confident with what I’m learning. Errors can be so easy to make, from letter case to typos. The run tool is not very helpful if you have an error in your script, so it was good to learn how to use the Debugging tool to take everything line by line. I think for practice this helped me as well. When I’m reading the script in the editor pane, my eyes jump around, and I try to pinpoint errors anywhere and everywhere. Using the debugging tool helped me review the script line by line, and fix errors line by line so I can tell which editing attempts work and which did not. I think the debugging tool will help me learn to be more organized in my script editing if nothing else.
We used a ‘try-except’ statement this week as well. This was a bit confusing for me while I was working through the exercise. I didn’t understand how it was placed around the existing blocks of script or why it was helpful. When I was working through the lab though, I understood how the ‘try-except’ statement can help tell you there is an error and move on to the next block of script so that it can run successfully. I can see how helpful this statement would be if you were writing a very long script and an error was preventing the whole script from running. It’s helpful to know there is an error in one block, but the rest of the script is just fine. Then you can go back and fix that error after you’ve completed the rest of the script.
The images above are of my Python console and flowcharts for each script.
In part 1, I ran the script to identify errors. I found that there was an upper case error for "fc" on row 12 and a typo/pleural error for "fields" on rows 14 & 15. Once I corrected all of the errors, the script listed the name of every column in the attributes table for the Parks shapefile.
In part 2, I used the Debugging tool to identify errors. I found a typo on row 14 in the file path (arcpy), a backslash error on row 15 in the file path (\ vs /), a spelling error on row 16 for the word "reference", and another typo/pleural error on row 21 for "maps". Once I corrected all of the errors, the script listed every map layer for an .aprx file.
In part 3, I used a 'try-except' statement to isolate an error in a block of script to allow the next block of script to run. I placed the 'Try' statement on row 13 before Part A, and indented the block of script after the "Try" statement . I placed the "Except" statement at the end of Part A and included a command to print "There has been a nontool error" when a TypeError was found in the script by Spyder. I unindeted the "except" statement. Once I did, Part B of the script ran successfully by listing the layers for an .aprx file and I received my error message for Part A.
Comments
Post a Comment