Python get error code - Исправление ошибок и поиск оптимальных решений проблем

In this Python Tutorial let us learn about the 3 different pieces of information that you can extract and use from the Exceptions caught on your except clauses, and see the best ways to use each of these pieces in our Python programs.

Let us start by learning what the 3 pieces of information are.

What kind of information can you get from Exceptions?

You can get the following 3 pieces of data from exceptions

Exception Type,
Exception Value a.k.a Error Message, and
Stack-trace or Traceback Object.

All three of the above information is printed out by the Python Interpreter when our program crashes due to an exception as shown in the following example

>> my_list = [1,2]
>> print (my_list[3])
Traceback (most recent call last):

  File "<ipython-input-35-63c7f9106be5>", line 1, in <module>
    print (my_list[3])

IndexError: list index out of range

Lines 3,4,5,6 shows the Stack-trace
Line 7 shows the Exception type and Error Message.

Our focus in this article is to learn how to extract the above 3 pieces individually in our except clauses and print them out as needed.

Hence, the rest of the article is all about answering the following questions

what does each of the information in the above list mean,
how to extract each of these 3 pieces individually and
how to use these pieces in our programs.

Piece#1: Printing Exception Type

The Exception Type refers to the class to which the Exception that you have just caught belongs to.

Extracting Piece#1 (Exception Type)

Let us improve our Example 1 above by putting the problematic code into try and except clauses.

try:
  my_list = [1,2]
  print (my_list[3])
except Exception as e:
  print(type(e))

Here, in the try clause, we have declared a List named my_list and initialized the list with 2 items. Then we have tried to print the 3rd/non-existent item in the list.

The except clause catches the IndexError exception and prints out Exception type.

On running the code, we will get the following output

<class 'IndexError'>

As you can see we just extracted and printed out the information about the class to which the exception that we have just caught belongs to!

But how exactly did we do that?
If you have a look at the except clause. In the line

except Exception as e:

what we have done is, we have assigned the caught exception to an object named “e”. Then by using the built-in python function type(), we have printed out the class name that the object e belongs to.

print(type(e))

Where to get more details about Exception Types

Now that we have the “Exception Type”, next we will probably need to get some information about that particular type so that we can get a better understanding of why our code has failed. In order to do that, the best place to start is the official documentation.

For built in exceptions you can have a look at the Python Documentation

For Exception types that come with the libraries that you use with your code, refer to the documentation of your library.

Piece#2: Printing Exception Value a.k.a Error message

The Exception type is definitely useful for debugging, but, a message like IndexError might sound cryptic and a good understandable error-message will make our job of debugging easier without having to look at the documentation.

In other words, if your program is to be run on the command line and you wish to log why the program just crashed then it is better to use an “Error message” rather than an “Exception Type”.

The example below shows how to print such an Error message.

try:
  my_list = [1,2]
  print (my_list[3])
except Exception as e:
  print(e)

This will print the default error message as follows

list index out of range

Each Exception type comes with its own error message. This can be retrieved using the built-in function print().

Say your program is going to be run by a not-so-tech-savvy user, in that case, you might want to print something friendlier. You can do so by passing in the string to be printed along with the constructor as follows.

try:
  raise IndexError('Custom message about IndexError')
except Exception as e:
  print(e)

This will print

Custom message about IndexError

To understand how the built-in function print() does this magic, and see some more examples of manipulating these error messages, I recommend reading my other article in the link below.

Python Exception Tutorial: Printing Error Messages (5 Examples!)

If you wish to print both the Error message and the Exception type, which I recommend, you can do so like below.

try:
  my_list = [1,2]
  print (my_list[3])
except Exception as e:
  print(repr(e))

This will print something like

IndexError('list index out of range')

Now that we have understood how to get control over the usage of Pieces 1 and 2, let us go ahead and look at the last and most important piece for debugging, the stack-trace which tells us where exactly in our program have the Exception occurred.

Piece#3: Printing/Logging the stack-trace using the traceback object

Stack-trace in Python is packed into an object named traceback object.

This is an interesting one as the traceback class in Python comes with several useful methods to exercise complete control over what is printed.

Let us see how to use these options using some examples!

import traceback

try:
  my_list = [1,2]
  print (my_list[3])
except Exception:
  traceback.print_exc()

This will print something like

Traceback (most recent call last):
  File "<ipython-input-38-f9a1ee2cf77a>", line 5, in <module>
    print (my_list[3])
IndexError: list index out of range

which contains the entire error messages printed by the Python interpreter if we fail to handle the exception.

Here, instead of crashing the program, we have printed this entire message using our exception handler with the help of the print_exc() method of the traceback class.

The above Example-6 is too simple, as, in the real-world, we will normally have several nested function calls which will result in a deeper stack. Let us see an example of how to control the output in such situations.

def func3():
  my_list = [1,2]
  print (my_list[3])

def func2():
  print('calling func3')
  func3()

def func1():
  print('calling func2')
  func2()

try:
  print('calling func1')
  func1()
except Exception as e:
    traceback.print_exc()

Here in the try clause we call func1(), which in-turn calls func2(), which in-turn calls func3(), which produces an IndexError. Running the code above we get the following output

calling func1
calling func2
calling func3
Traceback (most recent call last):
  File "<ipython-input-42-2267707e164f>", line 15, in <module>
    func1()
  File "<ipython-input-42-2267707e164f>", line 11, in func1
    func2()
  File "<ipython-input-42-2267707e164f>", line 7, in func2
    func3()
  File "<ipython-input-42-2267707e164f>", line 3, in func3
    print (my_list[3])
IndexError: list index out of range

Say we are not interested in some of the above information. Say we just want to print out the Traceback and skip the error message and Exception type (the last line above), then we can modify the code like shown below.

def func3():
  my_list = [1,2]
  print (my_list[3])

def func2():
  func3()

def func1():
  func2()

try:
  func1()
except Exception as e:
    traceback_lines = traceback.format_exc().splitlines()
    for line in traceback_lines:
      if line != traceback_lines[-1]:
        print(line)

Here we have used the format_exc() method available in the traceback class to get the traceback information as a string and used splitlines() method to transform the string into a list of lines and stored that in a list object named traceback_lines

Then with the help of a simple for loop we have skipped printing the last line with index of -1 to get an output like below

Traceback (most recent call last):
  File "<ipython-input-43-aff649563444>", line 3, in <module>
    func1()
  File "<ipython-input-42-2267707e164f>", line 11, in func1
    func2()
  File "<ipython-input-42-2267707e164f>", line 7, in func2
    func3()
  File "<ipython-input-42-2267707e164f>", line 3, in func3
    print (my_list[3])

Another interesting variant of formatting the information in the traceback object is to control the depth of stack that is actually printed out.

If your program uses lots of external library code, odds are the stack will get very deep, and printing out each and every level of function call might not be very useful. If you ever find yourself in such a situation you can set the limit argument in the print_exc() method like shown below.

traceback.print_exc(limit=2, file=sys.stdout)

This will limit the number of levels to 2. Let us use this line of code in our Example and see how that behaves

def func3():
  my_list = [1,2]
  print (my_list[3])

def func2():
  func3()

def func1():
  func2()

try:
  func1()
except Exception as e:
  traceback.print_exc(limit=2)

This will print

Traceback (most recent call last):
  File "<ipython-input-44-496132ff4faa>", line 12, in <module>
    func1()
  File "<ipython-input-44-496132ff4faa>", line 9, in func1
    func2()
IndexError: list index out of range

As you can see, we have printed only 2 levels of the stack and skipped the 3rd one, just as we wanted!

You can do more things with traceback like formatting the output to suit your needs. If you are interested to learn even more things to do, refer to the official documentation on traceback here

Now that we have seen how to exercise control over what gets printed and how to format them, next let us have a look at some best practices on when to use which piece of information

Best Practices while Printing Exception messages

When to Use Which Piece

Use Piece#1 only on very short programs and only during the development/testing phase to get some clues on the Exceptions without letting the interpreter crash your program. Once finding out, implement specific handlers to do something about these exceptions. If you are not sure how to handle the exceptions have a look at my other article below where I have explained 3 ways to handle Exceptions
Exceptions in Python: Everything You Need To Know!
Use Piece#2 to print out some friendly information either for yourself or for your user to inform them what exactly is happening.
Use all 3 pieces on your finished product, so that if an exception ever occurs while your program is running on your client’s computer, you can log the errors and have use that information to fix your bugs.

Where to print

One point worth noting here is that the default file that print() uses is the stdout file stream and not the stderr stream. To use stderr instead, you can modify the code like this

import sys
try:
  #some naughty statements that irritate us with exceptions
except Exception as e:
  print(e, file=sys.stderr)

The above code is considered better practice, as errors are meant to go to stderr and not stdout.

You can always print these into a separate log file too if that is what you need. This way, you can organize the logs collected in a better manner by separating the informational printouts from the error printouts.

How to print into log files

If you are going to use a log file I suggest using python’s logging module instead of print() statements, as described here

If you are interested in learning how to manually raise exceptions, and what situations you might need to do that you can read this article below

Python: Manually throw/raise an Exception using the “raise” statement

If you are interested in catching and handling multiple exception in a single except clause, you can this article below

Python: 3 Ways to Catch Multiple Exceptions in a single “except” clause

And with that, I will conclude this article!
I hope you enjoyed reading this article and got some value out of it!
Feel free to share it with your friends and colleagues!

Источник

Traceback is the message or information or a general report along with some data, provided by Python that helps us know about an error that has occurred in our program. It’s also called raising an exception in technical terms. For any development work, error handling is one of the crucial parts when a program is being written. So, the first step in handling errors is knowing the most frequent errors we will be facing in our code.

Tracebacks provide us with a good amount of information and some messages regarding the error that occurred while running the program. Thus, it’s very important to get a general understanding of the most common errors.

Also read: Tricks for Easier Debugging in Python

Tracebacks are often referred to with certain other names like stack trace, backtrace, or stack traceback. A stack is an abstract concept in all programming languages, which just refers to a place in the system’s memory or the processor’s core where the instructions are being executed one by one. And whenever there is an error while going through the code, tracebacks try to tell us the location as well as the kind of errors it has encountered while executing those instructions.

Some of the most common Tracebacks in Python

Here’s a list of the most common tracebacks that we encounter in Python. We will also try to understand the general meaning of these errors as we move further in this article.

SyntaxError
NameError
IndexError
TypeError
AttributeError
KeyError
ValueError
ModuleNotFound and ImportError

General overview of a Traceback in Python

Before going through the most common types of tracebacks, let’s try to get an overview of the structure of a general stack trace.

# defining a function
def multiply(num1, num2):
    result = num1 * num2
    print(results)

# calling the function
multiply(10, 2)

Output:

Traceback (most recent call last):
  File "d:Pythontraceback.py", line 6, in <module>
    multiply(10, 2)
  File "d:Pythontraceback.py", line 3, in multiply
    print(results)
NameError: name 'results' is not defined. Did you mean: 'result'?

Explanation:

Python is trying to help us out by giving us all the information about an error that has occurred while executing the program. The last line of the output says that it’s supposedly a NameError and even suggesting us a solution. Python is also trying to tell us the line number that might be the source of the error.

We can see that we have a variable name mismatch in our code. Instead of using “result”, as we earlier declared in our code, we have written “results”, which throws an error while executing the program.

So, this is the general structural hierarchy for a Traceback in Python which also implies that Python tracebacks should be read from bottom to top, which is not the case in most other programming languages.

1. SyntaxError

All programming languages have their specific syntax. If we miss out on that syntax, the program will throw an error. The code has to be parsed first only then it will give us the desired output. Thus, we have to make sure of the correct syntax for it to run correctly.

Let’s try to see the SyntaxError exception raised by Python.

# defining a function
def multiply(num1, num2):
    result = num1 * num2
    print "result"

# calling the function
multiply(10, 2)

Output:

File "d:Pythontraceback.py", line 4
    print "result"
    ^^^^^^^^^^^^^^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)?

Explanation:

When we try to run the above code, we see a SyntaxError exception being raised by Python. To print output in Python3.x, we need to wrap it around with a parenthesis. We can see the location of our error too, with the “^” symbol displayed below our error.

2. NameError

While writing any program, we declare variables, functions, and classes and also import modules into it. While making use of these in our program, we need to make sure that the declared things should be referenced correctly. On the contrary, if we make some kind of mistake, Python will throw an error and raise an exception.

Let’s see an example of NameError in Python.

# defining a function
def multiply(num1, num2):
    result = num1 * num2
    print(result)

# calling the function
multipli(10, 2)

Output:

Traceback (most recent call last):
  File "d:Pythontraceback.py", line 8, in <module>
    multipli(10, 2)
NameError: name 'multipli' is not defined. Did you mean: 'multiply'?

Explanation:

Our traceback says that the name “multipli” is not defined and it’s a NameError. We have not defined the variable “multipli”, hence the error occurred.

3. IndexError

Working with indexes is a very common pattern in Python. We have to iterate over various data structures in Python to perform operations on them. Index signifies the sequence of a data structure such as a list or a tuple. Whenever we try to retrieve some kind of index data from a series or sequence which is not present in our data structure, Python throws an error saying that there is an IndexError in our code.

Let’s see an example of it.

# declaring a list
my_list = ["apple", "orange", "banana", "mango"]

# Getting the element at the index 5 from our list
print(my_list[5])

Output:

Traceback (most recent call last):
  File "d:Pythontraceback.py", line 5, in <module>
    print(my_list[5])
IndexError: list index out of range

Explanation:

Our traceback says that we have an IndexError at line 5. It’s evident from our stack trace that our list does not contain any element at index 5, and thus it is out of range.

4. TypeError

Python throws a TypeError when trying to perform an operation or use a function with the wrong type of objects being used together in that operation.

Let’s see an example.

# declaring variables
first_num = 10
second_num = "15"

# Printing the sum
my_sum = first_num + second_num
print(my_sum)

Output:

Traceback (most recent call last):
  File "d:Pythontraceback.py", line 6, in <module>
    my_sum = first_num + second_num
TypeError: unsupported operand type(s) for +: 'int' and 'str'

Explanation:

In our code, we are trying to calculate the sum of two numbers. But Python is raising an exception saying that there is a TypeError for the operand “+” at line number 6. The stack trace is telling us that the addition of an integer and a string is invalid since their types do not match.

5. AttributeError

Whenever we try to access an attribute on an object which is not available on that particular object, Python throws an Attribute Error.

Let’s go through an example.

# declaring a tuple
my_tuple = (1, 2, 3, 4)

# Trying to append an element to our tuple
my_tuple.append(5)

# Print the result
print(my_tuple)

Output:

Traceback (most recent call last):
  File "d:Pythontraceback.py", line 5, in <module>    
    my_tuple.append(5)
AttributeError: 'tuple' object has no attribute 'append'

Explanation:

Python says that there is an AttributeError for the object “tuple” at line 5. Since tuples are immutable data structures and we are trying to use the method “append” on it. Thus, there is an exception raised by Python here. Tuple objects do not have an attribute “append” as we are trying to mutate the same which is not allowed in Python.

6. KeyError

Dictionary is another data structure in Python. We use it all the time in our programs. It is composed of Key: Value pairs and we need to access those keys and values whenever required. But what happens if we try to search for a key in our dictionary which is not present?

Let’s try using a key that is not present and see what Python has to say about that.

# dictionary
my_dict = {"name": "John", "age": 54, "job": "Programmer"}

# Trying to access info from our dictionary object
get_info = my_dict["email"]

# Print the result
print(get_info)

Output:

Traceback (most recent call last):
  File "d:Pythontraceback.py", line 5, in <module>
    get_info = my_dict["email"]
KeyError: 'email'

Explanation:

In the above example, we are trying to access the value for the key “email”. Well, Python searched for the key “email” in our dictionary object and raised an exception with a stack trace. The traceback says, there is a KeyError in our program at line 5. The provided key is nowhere to be found in the specified object, hence the error.

7. ValueError

The ValueError exception is raised by Python, whenever there is an incorrect value in a specified data type. The data type of the provided argument may be correct, but if it’s not an appropriate value, Python will throw an error for it.

Let’s see an example.

import math

# Variable declaration
my_num = -16

# Check the data type
print(f"The data type is: {type(my_num)}") # The data type is: <class 'int'>

# Trying to get the square root of our number
my_sqrt = math.sqrt(my_num)

# Print the result
print(my_sqrt)

Output:

The data type is: <class 'int'>
Traceback (most recent call last):
  File "d:Pythontraceback.py", line 10, in <module>
    my_sqrt = math.sqrt(my_num)
ValueError: math domain error

Explanation:

In the example above, we are trying to get the square root of a number using the in-built math module in Python. We are using the correct data type “int” as an argument to our function, but Python is throwing a traceback with ValueError as an exception.

This is because we can’t get a square root for a negative number, hence, it’s an incorrect value for our argument and Python tells us about the error saying that it’s a ValueError at line 10.

8. ImportError and ModuleNotFoundError

ImportError exception is raised by Python when there is an error in importing a specific module that does not exist. ModuleNotFound comes up as an exception when there is an issue with the specified path for the module which is either invalid or incorrect.

Let’s try to see these errors in action.

ImportError Example:

# Import statement
from math import addition

Output:

Traceback (most recent call last):
  File "d:Pythontraceback.py", line 2, in <module>
    from math import addition
ImportError: cannot import name 'addition' from 'math' (unknown location)

ModuleNotFoundError Example:

Output:

Traceback (most recent call last):
  File "d:Pythontraceback.py", line 1, in <module>
    import addition
ModuleNotFoundError: No module named 'addition'

Explanation:

ModuleNotFoundError is a subclass of ImportError since both of them output similar kinds of errors and can be avoided using try and except blocks in Python.

Summary

In this article, we went through the most common types of errors or tracebacks that we encounter while writing Python code. Making mistakes or introducing a bug in any program that we write is very common for all levels of developers. Python being a very popular, user-friendly, and easy-to-use language has some great built-in tools to help us as much as it can while we develop something. Traceback is a great example of one of those tools and a fundamental concept to understand while learning Python.

Reference

traceback Documentation

Источник

You can set an exit code for a process via sys.exit() and retrieve the exit code via the exitcode attribute on the multiprocessing.Process class.

In this tutorial you will discover how to get and set exit codes for processes in Python.

Let’s get started.

A process is a running instance of a computer program.

Every Python program is executed in a Process, which is a new instance of the Python interpreter. This process has the name MainProcess and has one thread used to execute the program instructions called the MainThread. Both processes and threads are created and managed by the underlying operating system.

Sometimes we may need to create new child processes in our program in order to execute code concurrently.

Python provides the ability to create and manage new processes via the multiprocessing.Process class.

In multiprocessing, we may need to report the success or failure of a task executed by a child process to other processes.

This can be achieved using exit codes.

What are exit codes and how can we use them between processes in Python?

How to Use Exit Codes in Python

An exit code or exit status is a way for one process to share with another whether it is finished and if so whether it finished successfully or not.

The exit status of a process in computer programming is a small number passed from a child process (or callee) to a parent process (or caller) when it has finished executing a specific procedure or delegated task.

— Exit status, Wikipedia.

An exit code is typically an integer value to represent success or failure of the process, but may also have an associated string message.

Let’s take a closer look at how we might set an exit code in a process and how another process might check the exit code of a process.

How to Set an Exit Code

A process can set the exit code automatically or explicitly.

For example, if the process exits normally, the exit code will be set to zero. If the process terminated with an error or exception, the exit code will be set to one.

A process can also set its exit code when explicitly exiting.

This can be achieved by calling the sys.exit() function and passing the exit code as an argument.

The sys.exit() function will raise a SystemExit exception in the current process, which will terminate the process.

The optional argument arg can be an integer giving the exit status (defaulting to zero), or another type of object.

— sys — System-specific parameters and functions

This function must be called in the main thread of the process and assumes that the SystemExit exception is not handled.

An argument value of 0 indicates a successful exit.

For example:

...

# exit successfully

sys.exit(0)

This is the default value of the argument and does not need to be specified.

For example:

...

# exit successfully

sys.exit()

Passing a value of None as an argument will also be interpreted as a successful exit.

For example:

...

# exit successfully

sys.exit(None)

A positive integer value indicates an unsuccessful exit, typically a value of one.

For example:

...

# exit unsuccessfully

sys.exit(1)

Alternatively, a string message may be provided as an argument.

This will be interpreted as an unsuccessful exit, e.g. a value of one, and the message will be reported on stderr.

For example:

...

# exit unsuccessfully

sys.exit(‘Something bad happened’)

You can learn more about the sys.exit() function in the tutorial:

Exit a Process with sys.exit() in Python

How to Get An Exit Code

Another process can get the exit code of a process via the “exitcode” attribute of the multiprocessing.Process instance for the process.

For example:

...

# get the exit code

code = process.exitcode

This means that we require a multiprocessing.Process instance for the process. For example, we may hang on to the process instance when creating the child process.

The exitcode attribute contains the value set by the process calling sys.exit(), or the value set automatically if the process ended normally or with an error.

If the child’s run() method returned normally, the exit code will be 0. If it terminated via sys.exit() with an integer argument N, the exit code will be N.

— multiprocessing — Process-based parallelism

If the process has not yet terminated, the exitcode value will not be set and will have the value None.

Common Exit Code Values

We may set exit codes for a process that are meaningful to the application.

This allows one process to communicate with another process regarding its specific status upon exit.

Additionally, there are also some commonly used exit code values.

For example, the integer value is typically between 0-255 and values 0-127 may be reserved for common situations or errors.

If it is an integer, zero is considered “successful termination” and any nonzero value is considered “abnormal termination” by shells and the like. Most systems require it to be in the range 0–127, and produce undefined results otherwise.

— sys — System-specific parameters and functions

For example:

0, None: Success
1: Error
2: Command line syntax errors
120: Error during process cleanup.
255: Exit code out of range.

A negative exit code may be assigned to a process if the process was terminated via a specific signal.

If it was terminated by signal N, the exit code will be the negative value -N.

— multiprocessing — Process-based parallelism

Now that we know how to get and set exit codes for a process, let’s look at some worked examples.

Confused by the multiprocessing module API?
Download my FREE PDF cheat sheet

Explicit Exit Codes

This section provides examples of explicitly setting an exit code when terminating a process.

Example of Successful Exit Code

We can explore setting a successful exit code in a child process.

In this example we will create a child process to exit a custom function. The child process will block for one second, and then exit with an explicitly successful exit code.

First, we can define the function to execute in the child function.

The function will sleep for a second, then call the sys.exit() function with an argument of zero to indicate a successful exit.

The task() function below implements this.

# function executed in a child process

def task():

# block for a moment

sleep(1)

# exit successfully

exit(0)

Next, in the main process, we will configure a new process instance to execute our task() function.

...

# configure a new process

child = Process(target=task)

The process is then started, and the main process blocks until the child process terminates.

...

# start the child process

child.start()

# wait for the child process to finish

child.join()

Finally, the main process retrieves the exit code for the child process and reports the value.

...

# check the exit code for the child process

code = child.exitcode

print(f‘Child exit code: {code}’)

Tying this together, the complete example is listed below.

# SuperFastPython.com

# example of a successful exit code

from time import sleep

from multiprocessing import Process

from sys import exit

# function executed in a child process

def task():

# block for a moment

sleep(1)

# exit successfully

exit(0)

# protect the entry point

if __name__ == ‘__main__’:

# configure a new process

child = Process(target=task)

# start the child process

child.start()

# wait for the child process to finish

child.join()

# check the exit code for the child process

code = child.exitcode

print(f‘Child exit code: {code}’)

Running the example first creates and starts the child process.

The main process then blocks until the child process terminates.

The child process sleeps for one second, then exits with an exit code of zero, indicating success.

The child process terminates then the main process continues on. It retrieves the exit code from the child process and reports the value.

In this case, we can see it has the value zero that we set in the child process when calling exit().

Next, let’s look at an example of an unsuccessful exit code.

Example of Unsuccessful Exit Code

We can explore an unsuccessful exit code.

Recall that any value other than zero indicates an unsuccessful end to the process.

We can update the example from the previous section so that the process calls exit() with a value of one.

...

# exit unsuccessfully

exit(1)

The updated task() function with this change is listed below.

# function executed in a child process

def task():

# block for a moment

sleep(1)

# exit unsuccessfully

exit(1)

Tying this together, the complete example is listed below.

# SuperFastPython.com

# example of an unsuccessful exit code

from time import sleep

from multiprocessing import Process

from sys import exit

# function executed in a child process

def task():

# block for a moment

sleep(1)

# exit unsuccessfully

exit(1)

# protect the entry point

if __name__ == ‘__main__’:

# configure a new process

child = Process(target=task)

# start the child process

child.start()

# wait for the child process to finish

child.join()

# check the exit code for the child process

code = child.exitcode

print(f‘Child exit code: {code}’)

Running the example first creates and starts the child process.

The main process then blocks until the child process terminates.

The child process sleeps for one second, then exits with an exit code of one, indicating an unsuccessful exit.

The child process terminates then the main process continues on. It retrieves the exit code from the child process and reports the value.

In this case, we can see it has the value of one that we set in the child process when calling exit().

Next, let’s look at an example of an unsuccessful exit code with a message.

Example of Error Message Exit Code

We can explore setting a string message as an exit code.

Recall, setting a string message as an exit code will indicate an unsuccessful exit, setting an exit code of one and reporting the string message on standard error (stderr).

We can update the previous example to set a string message when calling sys.exit().

...

# exit unsuccessfully with a message

exit(‘Something bad happened’)

The updated task() function with this change is listed below.

# function executed in a child process

def task():

# block for a moment

sleep(1)

# exit unsuccessfully with a message

exit(‘Something bad happened’)

Tying this together, the complete example is listed below.

# SuperFastPython.com

# example of an unsuccessful exit code message

from time import sleep

from multiprocessing import Process

from sys import exit

# function executed in a child process

def task():

# block for a moment

sleep(1)

# exit unsuccessfully with a message

exit(‘Something bad happened’)

# protect the entry point

if __name__ == ‘__main__’:

# configure a new process

child = Process(target=task)

# start the child process

child.start()

# wait for the child process to finish

child.join()

# check the exit code for the child process

code = child.exitcode

print(f‘Child exit code: {code}’)

Running the example first creates and starts the child process.

The main process then blocks until the child process terminates.

The child process sleeps for one second, then exits with an exit code of a string message, indicating an unsuccessful exit.

The child process terminates, reports the string message to standard error, then the main process continues on.

The main process then retrieves the exit code from the child process and reports the value.

In this case, we can see that the message was reported automatically, and that the exit code has the value of one, indicating an unsuccessful exit.

Something bad happened

Child exit code: 1

Free Python Multiprocessing Course

Download my multiprocessing API cheat sheet and as a bonus you will get FREE access to my 7-day email course.

Discover how to use the Python multiprocessing module including how to create and start child processes and how to use a mutex locks and semaphores.

Learn more

Automatic Exit Codes

This section provides examples of automatically setting an exit code when terminating a process.

Automatic Exit Code On Normal Exit

In this case we can explore the exit code set automatically when a Python process exits normally.

Recall that the exit code is set to zero indicating a successful exit when a Python process exits normally.

We can achieve this by updating the previous example to remove the call to sys.exit() from the task() function executed in a child process.

The updated task() function with this change is listed below.

# function executed in a child process

def task():

# block for a moment

sleep(1)

Tying this together, the complete example is listed below.

# SuperFastPython.com

# example of a normal successful exit for a process

from time import sleep

from multiprocessing import Process

from sys import exit

# function executed in a child process

def task():

# block for a moment

sleep(1)

# protect the entry point

if __name__ == ‘__main__’:

# configure a new process

child = Process(target=task)

# start the child process

child.start()

# wait for the child process to finish

child.join()

# check the exit code for the child process

code = child.exitcode

print(f‘Child exit code: {code}’)

Running the example first creates and starts the child process.

The main process then blocks until the child process terminates.

The child process sleeps for one second, then exits normally with no explicit exit code

The child process terminates then the main process continues on. It retrieves the exit code from the child process and reports the value.

In this case, we can see it has the value zero indicating a successful exit was set automatically when the child process exited normally.

Automatic Exit Code On Exception

In this case we can explore the exit code set automatically when a Python process exits with an exception.

Recall that the exit code is set to one indicating an unsuccessful exit when a Python process exits with an exception.

We can achieve this by updating the previous example to raise an exception in the function executed by the child process.

...

# raise an exception

raise Exception(‘Something bad happened’)

The updated task() function with this change is listed below.

# function executed in a child process

def task():

# block for a moment

sleep(1)

# raise an exception

raise Exception(‘Something bad happened’)

Tying this together, the complete example is listed below.

# SuperFastPython.com

# example of a unsuccessful exit for exiting with exception

from time import sleep

from multiprocessing import Process

from sys import exit

# function executed in a child process

def task():

# block for a moment

sleep(1)

# raise an exception

raise Exception(‘Something bad happened’)

# protect the entry point

if __name__ == ‘__main__’:

# configure a new process

child = Process(target=task)

# start the child process

child.start()

# wait for the child process to finish

child.join()

# check the exit code for the child process

code = child.exitcode

print(f‘Child exit code: {code}’)

Running the example first creates and starts the child process.

The main process then blocks until the child process terminates.

The child process sleeps for one second, then exits by raising an exception.

The exception stack trace is reported to standard error, the default behavior for handling an exception in a child process

The child process terminates then the main process continues on. It retrieves the exit code from the child process and reports the value.

In this case, we can see it has the value zero indicating an unsuccessful exit was set automatically when the child process exited with an exception.

Process Process-1:

Traceback (most recent call last):

…

Exception: Something bad happened

Child exit code: 1

Takeaways

You now know how to get and set exit codes for processes in Python.

Do you have any questions?
Ask your questions in the comments below and I will do my best to answer.

Photo by David Maginley on Unsplash

Источник

In Python, all exceptions must be instances of a class that derives from
BaseException. In a try statement with an except
clause that mentions a particular class, that clause also handles any exception
classes derived from that class (but not exception classes from which it is
derived). Two exception classes that are not related via subclassing are never
equivalent, even if they have the same name.

The built-in exceptions listed below can be generated by the interpreter or
built-in functions. Except where mentioned, they have an “associated value”
indicating the detailed cause of the error. This may be a string or a tuple of
several items of information (e.g., an error code and a string explaining the
code). The associated value is usually passed as arguments to the exception
class’s constructor.

User code can raise built-in exceptions. This can be used to test an exception
handler or to report an error condition “just like” the situation in which the
interpreter raises the same exception; but beware that there is nothing to
prevent user code from raising an inappropriate error.

The built-in exception classes can be subclassed to define new exceptions;
programmers are encouraged to derive new exceptions from the Exception
class or one of its subclasses, and not from BaseException. More
information on defining exceptions is available in the Python Tutorial under
User-defined Exceptions.

When raising (or re-raising) an exception in an except or
finally clause
__context__ is automatically set to the last exception caught; if the
new exception is not handled the traceback that is eventually displayed will
include the originating exception(s) and the final exception.

When raising a new exception (rather than using a bare raise to re-raise
the exception currently being handled), the implicit exception context can be
supplemented with an explicit cause by using from with
raise:

raise new_exc from original_exc

The expression following from must be an exception or None. It
will be set as __cause__ on the raised exception. Setting
__cause__ also implicitly sets the __suppress_context__
attribute to True, so that using raise new_exc from None
effectively replaces the old exception with the new one for display
purposes (e.g. converting KeyError to AttributeError, while
leaving the old exception available in __context__ for introspection
when debugging.

The default traceback display code shows these chained exceptions in
addition to the traceback for the exception itself. An explicitly chained
exception in __cause__ is always shown when present. An implicitly
chained exception in __context__ is shown only if __cause__
is None and __suppress_context__ is false.

In either case, the exception itself is always shown after any chained
exceptions so that the final line of the traceback always shows the last
exception that was raised.

5.1. Base classes¶

The following exceptions are used mostly as base classes for other exceptions.

exception BaseException¶

The base class for all built-in exceptions. It is not meant to be directly
inherited by user-defined classes (for that, use Exception). If
str() is called on an instance of this class, the representation of
the argument(s) to the instance are returned, or the empty string when
there were no arguments.

args¶: The tuple of arguments given to the exception constructor. Some built-in
exceptions (like OSError) expect a certain number of arguments and
assign a special meaning to the elements of this tuple, while others are
usually called only with a single string giving an error message.

with_traceback(tb)¶

This method sets tb as the new traceback for the exception and returns
the exception object. It is usually used in exception handling code like
this:

try:
    ...
except SomeException:
    tb = sys.exc_info()[2]
    raise OtherException(...).with_traceback(tb)

exception Exception¶: All built-in, non-system-exiting exceptions are derived from this class. All
user-defined exceptions should also be derived from this class.

exception ArithmeticError¶: The base class for those built-in exceptions that are raised for various
arithmetic errors: OverflowError, ZeroDivisionError,
FloatingPointError.

exception BufferError¶: Raised when a buffer related operation cannot be
performed.

exception LookupError¶: The base class for the exceptions that are raised when a key or index used on
a mapping or sequence is invalid: IndexError, KeyError. This
can be raised directly by codecs.lookup().

5.2. Concrete exceptions¶

The following exceptions are the exceptions that are usually raised.

exception AssertionError¶: Raised when an assert statement fails.

exception AttributeError¶: Raised when an attribute reference (see Attribute references) or
assignment fails. (When an object does not support attribute references or
attribute assignments at all, TypeError is raised.)

exception EOFError¶: Raised when the input() function hits an end-of-file condition (EOF)
without reading any data. (N.B.: the io.IOBase.read() and
io.IOBase.readline() methods return an empty string when they hit EOF.)

exception FloatingPointError¶: Raised when a floating point operation fails. This exception is always defined,
but can only be raised when Python is configured with the
--with-fpectl option, or the WANT_SIGFPE_HANDLER symbol is
defined in the pyconfig.h file.

exception GeneratorExit¶: Raised when a generator or coroutine is closed;
see generator.close() and coroutine.close(). It
directly inherits from BaseException instead of Exception since
it is technically not an error.

exception ImportError¶

Raised when the import statement has troubles trying to
load a module. Also raised when the “from list” in from ... import
has a name that cannot be found.

The name and path attributes can be set using keyword-only
arguments to the constructor. When set they represent the name of the module
that was attempted to be imported and the path to any file which triggered
the exception, respectively.

Changed in version 3.3: Added the name and path attributes.

exception ModuleNotFoundError¶

A subclass of ImportError which is raised by import
when a module could not be located. It is also raised when None
is found in sys.modules.

New in version 3.6.

exception IndexError¶: Raised when a sequence subscript is out of range. (Slice indices are
silently truncated to fall in the allowed range; if an index is not an
integer, TypeError is raised.)

exception KeyError¶: Raised when a mapping (dictionary) key is not found in the set of existing keys.

exception KeyboardInterrupt¶: Raised when the user hits the interrupt key (normally Control-C or
Delete). During execution, a check for interrupts is made
regularly. The exception inherits from BaseException so as to not be
accidentally caught by code that catches Exception and thus prevent
the interpreter from exiting.

exception MemoryError¶: Raised when an operation runs out of memory but the situation may still be
rescued (by deleting some objects). The associated value is a string indicating
what kind of (internal) operation ran out of memory. Note that because of the
underlying memory management architecture (C’s malloc() function), the
interpreter may not always be able to completely recover from this situation; it
nevertheless raises an exception so that a stack traceback can be printed, in
case a run-away program was the cause.

exception NameError¶: Raised when a local or global name is not found. This applies only to
unqualified names. The associated value is an error message that includes the
name that could not be found.

exception NotImplementedError¶: This exception is derived from RuntimeError. In user defined base
classes, abstract methods should raise this exception when they require
derived classes to override the method, or while the class is being
developed to indicate that the real implementation still needs to be added.

Note

It should not be used to indicate that an operator or method is not
meant to be supported at all – in that case either leave the operator /
method undefined or, if a subclass, set it to None.

Note

NotImplementedError and NotImplemented are not interchangeable,
even though they have similar names and purposes. See
NotImplemented for details on when to use it.

exception OSError([arg])¶

exception OSError(errno, strerror[, filename[, winerror[, filename2]]])

This exception is raised when a system function returns a system-related
error, including I/O failures such as “file not found” or “disk full”
(not for illegal argument types or other incidental errors).

The second form of the constructor sets the corresponding attributes,
described below. The attributes default to None if not
specified. For backwards compatibility, if three arguments are passed,
the args attribute contains only a 2-tuple
of the first two constructor arguments.

The constructor often actually returns a subclass of OSError, as
described in OS exceptions below. The particular subclass depends on
the final errno value. This behaviour only occurs when
constructing OSError directly or via an alias, and is not
inherited when subclassing.

errno¶: A numeric error code from the C variable errno.

winerror¶

Under Windows, this gives you the native
Windows error code. The errno attribute is then an approximate
translation, in POSIX terms, of that native error code.

Under Windows, if the winerror constructor argument is an integer,
the errno attribute is determined from the Windows error code,
and the errno argument is ignored. On other platforms, the
winerror argument is ignored, and the winerror attribute
does not exist.

strerror¶: The corresponding error message, as provided by
the operating system. It is formatted by the C
functions perror() under POSIX, and FormatMessage()
under Windows.

filename¶
filename2¶: For exceptions that involve a file system path (such as open() or
os.unlink()), filename is the file name passed to the function.
For functions that involve two file system paths (such as
os.rename()), filename2 corresponds to the second
file name passed to the function.

Changed in version 3.3: EnvironmentError, IOError, WindowsError,
socket.error, select.error and
mmap.error have been merged into OSError, and the
constructor may return a subclass.

Changed in version 3.4: The filename attribute is now the original file name passed to
the function, instead of the name encoded to or decoded from the
filesystem encoding. Also, the filename2 constructor argument and
attribute was added.

exception OverflowError¶: Raised when the result of an arithmetic operation is too large to be
represented. This cannot occur for integers (which would rather raise
MemoryError than give up). However, for historical reasons,
OverflowError is sometimes raised for integers that are outside a required
range. Because of the lack of standardization of floating point exception
handling in C, most floating point operations are not checked.

exception RecursionError¶

This exception is derived from RuntimeError. It is raised when the
interpreter detects that the maximum recursion depth (see
sys.getrecursionlimit()) is exceeded.

New in version 3.5: Previously, a plain RuntimeError was raised.

exception ReferenceError¶: This exception is raised when a weak reference proxy, created by the
weakref.proxy() function, is used to access an attribute of the referent
after it has been garbage collected. For more information on weak references,
see the weakref module.

exception RuntimeError¶: Raised when an error is detected that doesn’t fall in any of the other
categories. The associated value is a string indicating what precisely went
wrong.

exception StopIteration¶

Raised by built-in function next() and an iterator‘s
__next__() method to signal that there are no further
items produced by the iterator.

The exception object has a single attribute value, which is
given as an argument when constructing the exception, and defaults
to None.

When a generator or coroutine function
returns, a new StopIteration instance is
raised, and the value returned by the function is used as the
value parameter to the constructor of the exception.

If a generator function defined in the presence of a from __future__ import generator_stop directive raises StopIteration, it will be
converted into a RuntimeError (retaining the StopIteration
as the new exception’s cause).

Changed in version 3.3: Added value attribute and the ability for generator functions to
use it to return a value.

Changed in version 3.5: Introduced the RuntimeError transformation.

exception StopAsyncIteration¶

Must be raised by __anext__() method of an
asynchronous iterator object to stop the iteration.

New in version 3.5.

exception SyntaxError¶

Raised when the parser encounters a syntax error. This may occur in an
import statement, in a call to the built-in functions exec()
or eval(), or when reading the initial script or standard input
(also interactively).

Instances of this class have attributes filename, lineno,
offset and text for easier access to the details. str()
of the exception instance returns only the message.

exception IndentationError¶: Base class for syntax errors related to incorrect indentation. This is a
subclass of SyntaxError.

exception TabError¶: Raised when indentation contains an inconsistent use of tabs and spaces.
This is a subclass of IndentationError.

exception SystemError¶

Raised when the interpreter finds an internal error, but the situation does not
look so serious to cause it to abandon all hope. The associated value is a
string indicating what went wrong (in low-level terms).

You should report this to the author or maintainer of your Python interpreter.
Be sure to report the version of the Python interpreter (sys.version; it is
also printed at the start of an interactive Python session), the exact error
message (the exception’s associated value) and if possible the source of the
program that triggered the error.

exception SystemExit¶

This exception is raised by the sys.exit() function. It inherits from
BaseException instead of Exception so that it is not accidentally
caught by code that catches Exception. This allows the exception to
properly propagate up and cause the interpreter to exit. When it is not
handled, the Python interpreter exits; no stack traceback is printed. The
constructor accepts the same optional argument passed to sys.exit().
If the value is an integer, it specifies the system exit status (passed to
C’s exit() function); if it is None, the exit status is zero; if
it has another type (such as a string), the object’s value is printed and
the exit status is one.

A call to sys.exit() is translated into an exception so that clean-up
handlers (finally clauses of try statements) can be
executed, and so that a debugger can execute a script without running the risk
of losing control. The os._exit() function can be used if it is
absolutely positively necessary to exit immediately (for example, in the child
process after a call to os.fork()).

code¶: The exit status or error message that is passed to the constructor.
(Defaults to None.)

exception TypeError¶

Raised when an operation or function is applied to an object of inappropriate
type. The associated value is a string giving details about the type mismatch.

This exception may be raised by user code to indicate that an attempted
operation on an object is not supported, and is not meant to be. If an object
is meant to support a given operation but has not yet provided an
implementation, NotImplementedError is the proper exception to raise.

Passing arguments of the wrong type (e.g. passing a list when an
int is expected) should result in a TypeError, but passing
arguments with the wrong value (e.g. a number outside expected boundaries)
should result in a ValueError.

exception UnboundLocalError¶: Raised when a reference is made to a local variable in a function or method, but
no value has been bound to that variable. This is a subclass of
NameError.

exception UnicodeError¶

Raised when a Unicode-related encoding or decoding error occurs. It is a
subclass of ValueError.

UnicodeError has attributes that describe the encoding or decoding
error. For example, err.object[err.start:err.end] gives the particular
invalid input that the codec failed on.

encoding¶: The name of the encoding that raised the error.

reason¶: A string describing the specific codec error.

object¶: The object the codec was attempting to encode or decode.

start¶: The first index of invalid data in object.

end¶: The index after the last invalid data in object.

exception UnicodeEncodeError¶: Raised when a Unicode-related error occurs during encoding. It is a subclass of
UnicodeError.

exception UnicodeDecodeError¶: Raised when a Unicode-related error occurs during decoding. It is a subclass of
UnicodeError.

exception UnicodeTranslateError¶: Raised when a Unicode-related error occurs during translating. It is a subclass
of UnicodeError.

exception ValueError¶: Raised when a built-in operation or function receives an argument that has the
right type but an inappropriate value, and the situation is not described by a
more precise exception such as IndexError.

exception ZeroDivisionError¶: Raised when the second argument of a division or modulo operation is zero. The
associated value is a string indicating the type of the operands and the
operation.

The following exceptions are kept for compatibility with previous versions;
starting from Python 3.3, they are aliases of OSError.

exception EnvironmentError¶

exception IOError¶

exception WindowsError¶: Only available on Windows.

5.2.1. OS exceptions¶

The following exceptions are subclasses of OSError, they get raised
depending on the system error code.

exception BlockingIOError¶

Raised when an operation would block on an object (e.g. socket) set
for non-blocking operation.
Corresponds to errno EAGAIN, EALREADY,
EWOULDBLOCK and EINPROGRESS.

In addition to those of OSError, BlockingIOError can have
one more attribute:

characters_written¶: An integer containing the number of characters written to the stream
before it blocked. This attribute is available when using the
buffered I/O classes from the io module.

exception ChildProcessError¶: Raised when an operation on a child process failed.
Corresponds to errno ECHILD.

exception ConnectionError¶

A base class for connection-related issues.

Subclasses are BrokenPipeError, ConnectionAbortedError,
ConnectionRefusedError and ConnectionResetError.

exception BrokenPipeError¶: A subclass of ConnectionError, raised when trying to write on a
pipe while the other end has been closed, or trying to write on a socket
which has been shutdown for writing.
Corresponds to errno EPIPE and ESHUTDOWN.

exception ConnectionAbortedError¶: A subclass of ConnectionError, raised when a connection attempt
is aborted by the peer.
Corresponds to errno ECONNABORTED.

exception ConnectionRefusedError¶: A subclass of ConnectionError, raised when a connection attempt
is refused by the peer.
Corresponds to errno ECONNREFUSED.

exception ConnectionResetError¶: A subclass of ConnectionError, raised when a connection is
reset by the peer.
Corresponds to errno ECONNRESET.

exception FileExistsError¶: Raised when trying to create a file or directory which already exists.
Corresponds to errno EEXIST.

exception FileNotFoundError¶: Raised when a file or directory is requested but doesn’t exist.
Corresponds to errno ENOENT.

exception InterruptedError¶

Raised when a system call is interrupted by an incoming signal.
Corresponds to errno EINTR.

Changed in version 3.5: Python now retries system calls when a syscall is interrupted by a
signal, except if the signal handler raises an exception (see PEP 475
for the rationale), instead of raising InterruptedError.

exception IsADirectoryError¶: Raised when a file operation (such as os.remove()) is requested
on a directory.
Corresponds to errno EISDIR.

exception NotADirectoryError¶: Raised when a directory operation (such as os.listdir()) is requested
on something which is not a directory.
Corresponds to errno ENOTDIR.

exception PermissionError¶: Raised when trying to run an operation without the adequate access
rights — for example filesystem permissions.
Corresponds to errno EACCES and EPERM.

exception ProcessLookupError¶: Raised when a given process doesn’t exist.
Corresponds to errno ESRCH.

exception TimeoutError¶: Raised when a system function timed out at the system level.
Corresponds to errno ETIMEDOUT.

New in version 3.3: All the above OSError subclasses were added.

5.3. Warnings¶

The following exceptions are used as warning categories; see the warnings
module for more information.

exception Warning¶: Base class for warning categories.

exception UserWarning¶: Base class for warnings generated by user code.

exception DeprecationWarning¶: Base class for warnings about deprecated features.

exception PendingDeprecationWarning¶: Base class for warnings about features which will be deprecated in the future.

exception SyntaxWarning¶: Base class for warnings about dubious syntax.

exception RuntimeWarning¶: Base class for warnings about dubious runtime behavior.

exception FutureWarning¶: Base class for warnings about constructs that will change semantically in the
future.

exception ImportWarning¶: Base class for warnings about probable mistakes in module imports.

exception UnicodeWarning¶: Base class for warnings related to Unicode.

exception BytesWarning¶: Base class for warnings related to bytes and bytearray.

exception ResourceWarning¶

Base class for warnings related to resource usage.

New in version 3.2.

5.4. Exception hierarchy¶

The class hierarchy for built-in exceptions is:

BaseException
 +-- SystemExit
 +-- KeyboardInterrupt
 +-- GeneratorExit
 +-- Exception
      +-- StopIteration
      +-- StopAsyncIteration
      +-- ArithmeticError
      |    +-- FloatingPointError
      |    +-- OverflowError
      |    +-- ZeroDivisionError
      +-- AssertionError
      +-- AttributeError
      +-- BufferError
      +-- EOFError
      +-- ImportError
      |    +-- ModuleNotFoundError
      +-- LookupError
      |    +-- IndexError
      |    +-- KeyError
      +-- MemoryError
      +-- NameError
      |    +-- UnboundLocalError
      +-- OSError
      |    +-- BlockingIOError
      |    +-- ChildProcessError
      |    +-- ConnectionError
      |    |    +-- BrokenPipeError
      |    |    +-- ConnectionAbortedError
      |    |    +-- ConnectionRefusedError
      |    |    +-- ConnectionResetError
      |    +-- FileExistsError
      |    +-- FileNotFoundError
      |    +-- InterruptedError
      |    +-- IsADirectoryError
      |    +-- NotADirectoryError
      |    +-- PermissionError
      |    +-- ProcessLookupError
      |    +-- TimeoutError
      +-- ReferenceError
      +-- RuntimeError
      |    +-- NotImplementedError
      |    +-- RecursionError
      +-- SyntaxError
      |    +-- IndentationError
      |         +-- TabError
      +-- SystemError
      +-- TypeError
      +-- ValueError
      |    +-- UnicodeError
      |         +-- UnicodeDecodeError
      |         +-- UnicodeEncodeError
      |         +-- UnicodeTranslateError
      +-- Warning
           +-- DeprecationWarning
           +-- PendingDeprecationWarning
           +-- RuntimeWarning
           +-- SyntaxWarning
           +-- UserWarning
           +-- FutureWarning
           +-- ImportWarning
           +-- UnicodeWarning
           +-- BytesWarning
           +-- ResourceWarning

Источник

Overview

Teaching: 30 min

Exercises: 0 min

Questions

How does Python report errors?

How can I handle errors in Python programs?

Objectives

To be able to read a traceback, and determine where the error took place and what type it is.

To be able to describe the types of situations in which syntax errors, indentation errors, name errors, index errors, and missing file errors occur.

Every programmer encounters errors,
both those who are just beginning,
and those who have been programming for years.
Encountering errors and exceptions can be very frustrating at times,
and can make coding feel like a hopeless endeavour.
However,
understanding what the different types of errors are
and when you are likely to encounter them can help a lot.
Once you know why you get certain types of errors,
they become much easier to fix.

Errors in Python have a very specific form,
called a traceback.
Let’s examine one:

# This code has an intentional error. You can type it directly or
# use it for reference to understand the error message below.
def favorite_ice_cream():
    ice_creams = [
        'chocolate',
        'vanilla',
        'strawberry'
    ]
    print(ice_creams[3])

favorite_ice_cream()

---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
<ipython-input-1-70bd89baa4df> in <module>()
      9     print(ice_creams[3])
      10
----> 11 favorite_ice_cream()

<ipython-input-1-70bd89baa4df> in favorite_ice_cream()
      7         'strawberry'
      8     ]
----> 9     print(ice_creams[3])
      10
      11 favorite_ice_cream()

IndexError: list index out of range

This particular traceback has two levels.
You can determine the number of levels by looking for the number of arrows on the left hand side.
In this case:

The first shows code from the cell above,
with an arrow pointing to Line 11 (which is favorite_ice_cream()).
The second shows some code in the function favorite_ice_cream,
with an arrow pointing to Line 9 (which is print(ice_creams[3])).

The last level is the actual place where the error occurred.
The other level(s) show what function the program executed to get to the next level down.
So, in this case, the program first performed a
function call to the function favorite_ice_cream.
Inside this function,
the program encountered an error on Line 6, when it tried to run the code print(ice_creams[3]).

Long Tracebacks

Sometimes, you might see a traceback that is very long
– sometimes they might even be 20 levels deep!
This can make it seem like something horrible happened,
but the length of the error message does not reflect severity, rather,
it indicates that your program called many functions before it encountered the error.
Most of the time, the actual place where the error occurred is at the bottom-most level,
so you can skip down the traceback to the bottom.

So what error did the program actually encounter?
In the last line of the traceback,
Python helpfully tells us the category or type of error (in this case, it is an IndexError)
and a more detailed error message (in this case, it says “list index out of range”).

If you encounter an error and don’t know what it means,
it is still important to read the traceback closely.
That way,
if you fix the error,
but encounter a new one,
you can tell that the error changed.
Additionally,
sometimes knowing where the error occurred is enough to fix it,
even if you don’t entirely understand the message.

If you do encounter an error you don’t recognize,
try looking at the
official documentation on errors.
However,
note that you may not always be able to find the error there,
as it is possible to create custom errors.
In that case,
hopefully the custom error message is informative enough to help you figure out what went wrong.

Syntax Errors

When you forget a colon at the end of a line,
accidentally add one space too many when indenting under an if statement,
or forget a parenthesis,
you will encounter a syntax error.
This means that Python couldn’t figure out how to read your program.
This is similar to forgetting punctuation in English:
for example,
this text is difficult to read there is no punctuation there is also no capitalization
why is this hard because you have to figure out where each sentence ends
you also have to figure out where each sentence begins
to some extent it might be ambiguous if there should be a sentence break or not

People can typically figure out what is meant by text with no punctuation,
but people are much smarter than computers.
If Python doesn’t know how to read the program,
it will give up and inform you with an error.
For example:

def some_function()
    msg = 'hello, world!'
    print(msg)
     return msg

  File "<ipython-input-3-6bb841ea1423>", line 1
    def some_function()
                       ^
SyntaxError: invalid syntax

Here, Python tells us that there is a SyntaxError on line 1,
and even puts a little arrow in the place where there is an issue.
In this case the problem is that the function definition is missing a colon at the end.

Actually, the function above has two issues with syntax.
If we fix the problem with the colon,
we see that there is also an IndentationError,
which means that the lines in the function definition do not all have the same indentation:

def some_function():
    msg = 'hello, world!'
    print(msg)
     return msg

  File "<ipython-input-4-ae290e7659cb>", line 4
    return msg
    ^
IndentationError: unexpected indent

Both SyntaxError and IndentationError indicate a problem with the syntax of your program,
but an IndentationError is more specific:
it always means that there is a problem with how your code is indented.

Tabs and Spaces

Some indentation errors are harder to spot than others.
In particular, mixing spaces and tabs can be difficult to spot
because they are both whitespace.
In the example below, the first two lines in the body of the function
some_function are indented with tabs, while the third line — with spaces.
If you’re working in a Jupyter notebook, be sure to copy and paste this example
rather than trying to type it in manually because Jupyter automatically replaces
tabs with spaces.
def some_function():
	msg = 'hello, world!'
	print(msg)
        return msg
Visually it is impossible to spot the error.
Fortunately, Python does not allow you to mix tabs and spaces.
  File "<ipython-input-5-653b36fbcd41>", line 4
    return msg
              ^
TabError: inconsistent use of tabs and spaces in indentation

Variable Name Errors

Another very common type of error is called a NameError,
and occurs when you try to use a variable that does not exist.
For example:

---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-7-9d7b17ad5387> in <module>()
----> 1 print(a)

NameError: name 'a' is not defined

Variable name errors come with some of the most informative error messages,
which are usually of the form “name ‘the_variable_name’ is not defined”.

Why does this error message occur?
That’s a harder question to answer,
because it depends on what your code is supposed to do.
However,
there are a few very common reasons why you might have an undefined variable.
The first is that you meant to use a
string, but forgot to put quotes around it:

---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-8-9553ee03b645> in <module>()
----> 1 print(hello)

NameError: name 'hello' is not defined

The second reason is that you might be trying to use a variable that does not yet exist.
In the following example,
count should have been defined (e.g., with count = 0) before the for loop:

for number in range(10):
    count = count + number
print('The count is:', count)

---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-9-dd6a12d7ca5c> in <module>()
      1 for number in range(10):
----> 2     count = count + number
      3 print('The count is:', count)

NameError: name 'count' is not defined

Finally, the third possibility is that you made a typo when you were writing your code.
Let’s say we fixed the error above by adding the line Count = 0 before the for loop.
Frustratingly, this actually does not fix the error.
Remember that variables are case-sensitive,
so the variable count is different from Count. We still get the same error,
because we still have not defined count:

Count = 0
for number in range(10):
    count = count + number
print('The count is:', count)

---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-10-d77d40059aea> in <module>()
      1 Count = 0
      2 for number in range(10):
----> 3     count = count + number
      4 print('The count is:', count)

NameError: name 'count' is not defined

Index Errors

Next up are errors having to do with containers (like lists and strings) and the items within them.
If you try to access an item in a list or a string that does not exist,
then you will get an error.
This makes sense:
if you asked someone what day they would like to get coffee,
and they answered “caturday”,
you might be a bit annoyed.
Python gets similarly annoyed if you try to ask it for an item that doesn’t exist:

letters = ['a', 'b', 'c']
print('Letter #1 is', letters[0])
print('Letter #2 is', letters[1])
print('Letter #3 is', letters[2])
print('Letter #4 is', letters[3])

Letter #1 is a
Letter #2 is b
Letter #3 is c

---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
<ipython-input-11-d817f55b7d6c> in <module>()
      3 print('Letter #2 is', letters[1])
      4 print('Letter #3 is', letters[2])
----> 5 print('Letter #4 is', letters[3])

IndexError: list index out of range

Here,
Python is telling us that there is an IndexError in our code,
meaning we tried to access a list index that did not exist.

File Errors

The last type of error we’ll cover today
are those associated with reading and writing files: FileNotFoundError.
If you try to read a file that does not exist,
you will receive a FileNotFoundError telling you so.
If you attempt to write to a file that was opened read-only, Python 3
returns an UnsupportedOperationError.
More generally, problems with input and output manifest as
IOErrors or OSErrors, depending on the version of Python you use.

file_handle = open('myfile.txt', 'r')

---------------------------------------------------------------------------
FileNotFoundError                         Traceback (most recent call last)
<ipython-input-14-f6e1ac4aee96> in <module>()
----> 1 file_handle = open('myfile.txt', 'r')

FileNotFoundError: [Errno 2] No such file or directory: 'myfile.txt'

One reason for receiving this error is that you specified an incorrect path to the file.
For example,
if I am currently in a folder called myproject,
and I have a file in myproject/writing/myfile.txt,
but I try to open myfile.txt,
this will fail.
The correct path would be writing/myfile.txt.
It is also possible that the file name or its path contains a typo.

A related issue can occur if you use the “read” flag instead of the “write” flag.
Python will not give you an error if you try to open a file for writing
when the file does not exist.
However,
if you meant to open a file for reading,
but accidentally opened it for writing,
and then try to read from it,
you will get an UnsupportedOperation error
telling you that the file was not opened for reading:

file_handle = open('myfile.txt', 'w')
file_handle.read()

---------------------------------------------------------------------------
UnsupportedOperation                      Traceback (most recent call last)
<ipython-input-15-b846479bc61f> in <module>()
      1 file_handle = open('myfile.txt', 'w')
----> 2 file_handle.read()

UnsupportedOperation: not readable

These are the most common errors with files,
though many others exist.
If you get an error that you’ve never seen before,
searching the Internet for that error type
often reveals common reasons why you might get that error.

Reading Error Messages

Read the Python code and the resulting traceback below, and answer the following questions:

How many levels does the traceback have?
What is the function name where the error occurred?
On which line number in this function did the error occur?
What is the type of error?
What is the error message?

# This code has an intentional error. Do not type it directly;
# use it for reference to understand the error message below.
def print_message(day):
    messages = {
        'monday': 'Hello, world!',
        'tuesday': 'Today is Tuesday!',
        'wednesday': 'It is the middle of the week.',
        'thursday': 'Today is Donnerstag in German!',
        'friday': 'Last day of the week!',
        'saturday': 'Hooray for the weekend!',
        'sunday': 'Aw, the weekend is almost over.'
    }
    print(messages[day])

def print_friday_message():
    print_message('Friday')

print_friday_message()

---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-1-4be1945adbe2> in <module>()
     14     print_message('Friday')
     15
---> 16 print_friday_message()

<ipython-input-1-4be1945adbe2> in print_friday_message()
     12
     13 def print_friday_message():
---> 14     print_message('Friday')
     15
     16 print_friday_message()

<ipython-input-1-4be1945adbe2> in print_message(day)
      9         'sunday': 'Aw, the weekend is almost over.'
     10     }
---> 11     print(messages[day])
     12
     13 def print_friday_message():

KeyError: 'Friday'

Solution

3 levels

print_message

11

KeyError

There isn’t really a message; you’re supposed
to infer that Friday is not a key in messages.

Identifying Syntax Errors

Read the code below, and (without running it) try to identify what the errors are.

Run the code, and read the error message. Is it a SyntaxError or an IndentationError?

Fix the error.

Repeat steps 2 and 3, until you have fixed all the errors.
def another_function
  print('Syntax errors are annoying.')
   print('But at least Python tells us about them!')
  print('So they are usually not too hard to fix.')
Solution

SyntaxError for missing (): at end of first line,
IndentationError for mismatch between second and third lines.
A fixed version is:
def another_function():
    print('Syntax errors are annoying.')
    print('But at least Python tells us about them!')
    print('So they are usually not too hard to fix.')

Identifying Variable Name Errors

Read the code below, and (without running it) try to identify what the errors are.

Run the code, and read the error message.
What type of NameError do you think this is?
In other words, is it a string with no quotes,
a misspelled variable,
or a variable that should have been defined but was not?

Fix the error.

Repeat steps 2 and 3, until you have fixed all the errors.
for number in range(10):
    # use a if the number is a multiple of 3, otherwise use b
    if (Number % 3) == 0:
        message = message + a
    else:
        message = message + 'b'
print(message)
Solution

3 NameErrors for number being misspelled, for message not defined,
and for a not being in quotes.

Fixed version:
message = ''
for number in range(10):
    # use a if the number is a multiple of 3, otherwise use b
    if (number % 3) == 0:
        message = message + 'a'
    else:
        message = message + 'b'
print(message)

Identifying Index Errors

Read the code below, and (without running it) try to identify what the errors are.

Run the code, and read the error message. What type of error is it?

Fix the error.
seasons = ['Spring', 'Summer', 'Fall', 'Winter']
print('My favorite season is ', seasons[4])
Solution

IndexError; the last entry is seasons[3], so seasons[4] doesn’t make sense.
A fixed version is:
seasons = ['Spring', 'Summer', 'Fall', 'Winter']
print('My favorite season is ', seasons[-1])

Key Points

Tracebacks can look intimidating, but they give us a lot of useful information about what went wrong in our program, including where the error occurred and what type of error it was.

An error having to do with the ‘grammar’ or syntax of the program is called a SyntaxError. If the issue has to do with how the code is indented, then it will be called an IndentationError.

A NameError will occur when trying to use a variable that does not exist. Possible causes are that a variable definition is missing, a variable reference differs from its definition in spelling or capitalization, or the code contains a string that is missing quotes around it.

Containers like lists and strings will generate errors if you try to access items in them that do not exist. This type of error is called an IndexError.

Trying to read a file that does not exist will give you an FileNotFoundError. Trying to read a file that is open for writing, or writing to a file that is open for reading, will give you an IOError.

Источник

What kind of information can you get from Exceptions?

Piece#1: Printing Exception Type

Extracting Piece#1 (Exception Type)

Where to get more details about Exception Types

Piece#2: Printing Exception Value a.k.a Error message

Piece#3: Printing/Logging the stack-trace using the traceback object

Best Practices while Printing Exception messages

When to Use Which Piece

Where to print

How to print into log files

Some of the most common Tracebacks in Python

General overview of a Traceback in Python

1. SyntaxError

2. NameError

3. IndexError

4. TypeError

5. AttributeError

6. KeyError

7. ValueError

8. ImportError and ModuleNotFoundError

Summary

Reference

How to Use Exit Codes in Python

How to Set an Exit Code

How to Get An Exit Code

Common Exit Code Values

Explicit Exit Codes

Example of Successful Exit Code

Example of Unsuccessful Exit Code

Example of Error Message Exit Code

Automatic Exit Codes

Automatic Exit Code On Normal Exit

Automatic Exit Code On Exception

Further Reading

Takeaways

5.1. Base classes¶

5.2. Concrete exceptions¶

5.2.1. OS exceptions¶

5.3. Warnings¶

5.4. Exception hierarchy¶

Overview

Long Tracebacks

Syntax Errors

Tabs and Spaces

Variable Name Errors

Index Errors

File Errors

Reading Error Messages

Solution

Identifying Syntax Errors

Solution

Identifying Variable Name Errors

Solution

Identifying Index Errors

Solution

Key Points