Debugging, Error Handling, and more Trials of Perseverance & Stoicism

Programming errors are unavoidable.  For the novice programmer they are an omnipresent threat, waiting at the ready to crash a script and destroy the prospect of an early evening, to test the already frayed nerves and severely waning patience of a long suffering student.  They are how we learn- the crux of our trial and error Python education, and we must adapt to handle them with grace.  Or at least know how to deal with and fix them, and not smash our computers in the process.

Debugging script, or finding and remedying errors therein, is a skill and an art in and of itself.  There are plenty of ways to do it- the dubugging tools in PythonWin, for example, can be exceedingly helpful, or inserting print statements to isolate where in the script the error is occurring.  Finding one's preferred method is, appropriately, a trial and error process.  The screenshot above is the output of one of three simple scripts, the task at hand was to isolate and fix the errors secreted within.  Simple syntax errors- incorrect capitalization, indentation or spelling- will prevent a script from running entirely, and, like all typos, are easy to inadvertently add when typing.  These errors are relatively easy to find and fix, though, especially with the spellcheck-like "check" tool available in PythonWin.  More difficult, without question, are logic and exception errors, which occur within the code's structure, and can be exceptionally difficult to isolate and fix.  These are the errors we are faced with in our second, more insidiously villainous, script.

Here we have the screenshot of an output that is a list of the layers in a map document.  This script was a rather wonderful lesson in perseverance, as well as finding and isolating exception errors.  There were eight total errors to locate, and it was not meant to be easy.  There is something to be said, however, for the satisfaction that comes from spending upwards of 2 hours scouring tutorials and Help documents, and finally reaching that Gestalt moment when all becomes clear and the error is removed.  It is one of the more gratifying experiences one can have, to be sure.  Working with the various modules, tools and processes within the script was pretty illuminating as well- as running through it line by line with the debugger several dozen times provides ample opportunity to become familiar with them.  Exception errors are not always easy to locate and remedy, but learning to do so is an invaluable skill.

The final output, which could be contended to have the easiest "solution," was also probably the trickiest, possibly because the solution wasn't very complicated.  The idea here was to allow an error to occur within the first part (part A), using a try-except statement, so that it didn't cause a runtime error that would stop the script, and the second part (part B) could produce its output regardless.  The concept behind the try-except condition was not the easiest to grasp though, which made its correct implementation quite onerous.  The idea behind it is to instruct the program to try to execute some block of code, and in the event of an exception to produce some alternate output- like an error message- rather than stopping altogether.  A condition that allows for exceptions without crashing the entire process is a useful one to know, and the time spent on this one was, like the first two, worth the trouble and frustration for the insight it provided.