GISProgramming: Module 4 - Debugging and Error Handling

     Debugging! This week was all about identifying and fixing errors in code. Some errors are simple to spot and easily fixed, such as incorrect spelling or spelling inconsistencies, case sensitivity, and incorrect indentation, to name a few. Other errors are not easy to see immediately, such as exceptions. These require the program to run to encounter the exception. The handy thing about Python is that it will provide information about the type of error and its location. For instance, exceptions will display in the interactive window stating the line in which the exception was raised.
     We were given several scripts to comb through to practice finding common errors, syntax errors, and exceptions. We also gave running a program in PythonWin debugger a try. I will go through each script and describe some of the errors I found and corrected. No logic errors were addressed in these exercises, only syntax errors and exceptions.  

Script 1
    The first script had two errors. The first error was a simple capitalization mistake and easily fixed. The second error was an exception that I did not catch until I tried to run the program. The exception raised was an "AttributeError." This type of exception is raised when an attribute reference or assignment fails.  I corrected this exception by correcting a spelling mistake. So, I didn't necessarily have to run the program to find this error but it helped me locate the line(s) that contained the error. This was handy because I didn't have to go through line by line and proof read. It, however, would have saved me some time if I had just noticed the spelling mistake in the first place. The screenshot of the interactive window below shows the results of the debugged program. This program gets and prints the names of the fields found in a particular shapefile.

Script 1 
A screenshot of the debugged and error corrected program
that results in a list of field names for a given shapefile.

Script 2
     The second script contained eight errors. As I encountered the errors it helped to write a comment on the side of the line in which I fixed the error. # That way I could keep track of the changes I was making to the script. Some of the errors I encountered were incorrect file paths, spelling mistakes, and a few exceptions (a TypeError and an AttributeError, for example). Once the program was debugged, when run it acquires and prints the names of the layers found in a data frame.   

Script 2
A screenshot of the successfully debugged program that results
in a list of the layers found in the data frame(s) of a given .mxd file.

Script 3

     The final script when run raised an exception. The goal for this script was to get the program to run despite the exception. I added a try-except statement to allow this program to run while printing the type of exception raised. The try-except statement is a handy tool for debugging. At first, I generated a lot of work for myself because I tried to fix the exception raised with a try-except statement but then encountered a different exception when I ran this "corrected" version of the program. I made another try-except statement for this new exception and again encountered another. I could not get this program to run. Then it hit me. I only had to use one try-except statement and then have the program print the exception raised. The program ran successfully after that. Phew. The results are displayed below. When this program runs, an exception is printed and the name, spatial reference, and scale of a given data frame is shown. 

Script 3
A screenshot of the final script in the exercise.
It shows the result of adding a try-except statement to catch
an exception and still run the remaining script in the program. 

     Are you still with me? At first I felt like learning debugging this early in the course was like being thrown into the deep end of the Python pool. This will pay off in the weeks to come, I am sure. I am still a little befuddled by the debugger but that is probably due to lack of exposure. I'd like to think that I will be a careful programmer but no one is perfect and debugging is essential to programming success. Now, if an exception is raised in my future programs I won't panic. Thanks debugging.




[Hopefully my brain won't fall out raising a MemoryError.]