Stack traces and errors

Back to main page

As a computer programmer, you are going to making lots and lots of mistakes in your code and they can arise from just about anything. Some of these errors can be found via Python’s built-in capabilities to log its high-level implementation of the call stack. We will discuss the stack trace a little bit in the section about runtime errors below.

Syntax errors

As an example, we will write the intentionally faulty program:

myString = 'Hello, World'
print(myString

If we attempt to run this program, we run into the following message:

  File "/home/itzsomebody/Desktop/example.py", line 2
    print(myString
         ^
SyntaxError: '(' was never closed

Here, Python is upset with us because there is a syntactical error in our program. Just as our teachers/instructors become upset with us for incorrect usage of grammatical rules of your language, so does Python for not following the rules of its language.

Runtime errors

Runtime errors occur while Python is actually running the program. We will also take this time to give an example of how stack traces can be useful. Consider the following program:

def print_cat_count():
    print('I have ' + 25 + ' cats')

print_cat_count()

This program will call the function print_cat_count() which is intended to announce how many cats I have (P.S. I do not have 25 cats). When run, we arrive at

Traceback (most recent call last):
  File "/home/itzsomebody/Desktop/example.py", line 4, in <module>
    print_cat_count()
  File "/home/itzsomebody/Desktop/example.py", line 2, in print_cat_count
    print('I have ' + 25 + ' cats')
          ~~~~~~~~~~^~~~
TypeError: can only concatenate str (not "int") to str

Notice that the stack trace tells us exactly how it got to that point in the code and also exactly what it tripped up on and precisely why it is upset. In this case, it is because Python is unsure of how we want to combine a string and integer together.

Semantic error

Semantic errors are also known as logic errors. Typically, the program will run without Python stopping it, but the behavior of the program is not expected. These errors are typically the ones that give programmers the most trouble and is why unit testing is such an integral component of software engineering.

Unfortunately, Python on its own does not offer a whole lot for the debugging experience of hunting down semantic errors, but various tools to exist to help find these. To this end, I suggest to the reader to learn how to use the debugging features on an IDE such as PyCharm or Spyder.

Back to main page