M3 Python Debugging and Error Handling

 Greetings Everyone,

This week saw us delving into Python script involving many more arcpy tools and purposes, but with one key twist. It was all about debugging, error handling, and script management designed to try segments of a script and provide work arounds to errors. Ultimately, three different scripts were used. The shells were all provided, and they had different end goals toward error correction. 

With errors in Python script, there are geoprocessing errors, and everything else unrelated to that. The practice and assignment worked with many of the common Python errors such as spelling mistakes, not importing appropriate modules, case sensitivity, wrong pathing, bad punctuation or indentation, and conditional assignment issues. For geoprocessing specifically, we add in workspace or environment identification issues, forgetting to check or omitting overwrite rules, multi-program data usage, and inappropriate parameters for objects being used by arc tools. 

This may sound like a lot, but the majority of the focus was on making common problems easier to identify and correct. This started with the first script highlighting some simple syntax errors. The correct out put is shown below. 

The second script involved significantly more errors, many simple fixes. But some drawing on having to cross reference the error presented in by the interpreter with data locations and objects within both the project catalog and imported data provided for the project. Its appropriate output is highlighted below. 

The third script was different. This script involved taking a known error, and applying a work around fix. The Try / Except statement was utilized to isolate the known error. This involved setting these statements, which allow the Python Interpreter to try a block of script, and upon identifying an error, provide a printout of the error and then continue with the remainder of the script. The first output below highlights this process through having the print statement that I injected as my exception, that an error has occurred, which says.... This way, the script shows that something happened, but it continued working on part B anyway, which then completed successfully. 

Continuing with the third script, and further exploring the Try / Except statement methodology, I have generated the below Flowchart. It highlights the process that I have essentially put into the script. I start part A, have a print statement acknowledging as such, then proceed to TRY a block of code. It has associated variables and a for statement for the Arc functions to work on a project file. The way that I envision this process, is that either the Try block works, or at some point an exception is encountered, which drives a separate output. Either of these paths then lead to ending part A and continuing with part B. 

Part B is not shown in the Diagram Above. It simply shows that after the process involving Part A, it would continue with the next starting point. A similar Try / Except statement can be utilized for the next block of script. Either the segment works as advertised, or the exception is there to trap it and provide a print out of what occurred instead. Thank you.

v/r

Brandon