Programming Module 3

 

Programming Module 3

In this Module we focused on an entirely different aspect of writing and scripting Python coding language. We learned about debugging and error handling and learned about the different types of errors that are commonly encountered when attempting to write, and execute code. 

Starting with syntax errors:

Syntax errors are arguably the most common errors that a script will contain. They can be anything from a missing colon, capitalize word or letter when it should be lower case, vise versa, an incorrectly typed file path, or even a missing pound sign for a comment. In IDLE a quick way to check for these types of errors is to use the ( Check Module ) feature while in the script editor. 

This will quickly tell you if there is or are current syntax errors in your script by popping up a window that states: Invalid Syntax with a red circled X next to it. 

The first script in this lab focused on these sorts of errors. 

In the above image of the first script, you can see the red lines which are my comments of what I had changed in order for the script to produce the correct output. 

First the variable fc was typed FC. Python does not like for variables to be in this format as it potentially confuses the program into thinking it represents something else. 

Second, was fields = arcpy.ListFields(fc) which was originally typed as (FC) at the end referring back to line 4. where fc was originally defined. 

Lastly, for field in fields: was originally typed as for fields in field: 

The original way the code was typed didn't make any sense because field is being defined as a new variable from the previously defined fields variable. 

If we inverted this it would cause an error because field is not a defined variable therefore we couldn't use it in this conditional statement. 

The second script focused our attention more on run time errors. 

Run time errors not like syntax errors are problems with in what way the code is being structured within the script in relation to the functions, methods, and use of variables. 

An example would be wanting to use a tool or command from the ArcPy library without importing the arcpy library first. 

In this script I encountered an interesting dilemma. 

I first began debugging the code in IDLE environment and was running into a rune time error concerning the line that states 

aprx = arcpy.mp.ArcGISProject(filepath)

My initial problem was actually because when I attempted to run the script in IDLE Shell, I still had the aprx open as I had been frequently revisiting the ArcGISPro Application to debug some of the code I was having issues with. 
It eventually dawned on me that what was happening was that the program could not successful save or edit the aprx file because it was open at the same time it attempted to run the code that was editing that specific file. 
Obviously if a file is open such as in word or excel, microsoft will not allow you to rename or make any changes to the file until it is closed. 

The second thing I learned about this specific function is that when I was editing this very same code in ArcGIS Notebooks, the line that states:   aprx = arcpy.mp.ArcGISProject(filepath) has to be changed to 

aprx = arcpy.mp.ArcGISProject("CURRENT")

I believe this is because the file path is referenced differently from one environment to another. Notebooks being built into and as a part of ArcGIS Pro was not able to reference itself from essentially a "3rd person" and needed to instead reference the file as ("CURRENT") to reflect the currently opened project. 
I'm sure I'll learn about this sort of thing in a later lab. 

Lastly is a script with an error that needed debugging but not in the straightforward method of correcting the problem code. 

In this script we instead used the try - except statement. 

A brief description of this tool would be that when using the first part of the statement the "try" portion, is essentially capturing lines or a line of code that there is a suspected error in, and then adding the except statement to continue processing the code that comes after. 

In this code I added a couple of extra print statements to explain that there was an error encountered in part A and then print the error the system encountered. 

In order to explain my thought process in a clearer fashion, below is a flowchart of how I determined my process for handling this error using the try / except method. 

In this flow chart you can see that I first identified where the problem code was, and this can either be an estimate or known line(s) of code.  

If encountering any errors after setting the except statement reset the location of the except statement and run again.