Demystifying Built-in Exceptions

00:00 As of Python 3.13, there are over 60 built-in exceptions. They represent errors and exceptional situations. Some can be encountered and raised directly, and some are used as base classes.

00:13 And don’t forget, Python is an object-oriented language. So all exceptions have their place in the exception class hierarchy.

00:20 Here’s a diagram of the class hierarchy. I couldn’t fit 60-plus exceptions on this slide, so these are the highlights. The exception class hierarchy starts with the BaseException at the top, which all exceptions inherit from and from there can be broken down into four sections.

00:36 First are the base classes. These are usually used as parent classes for other exceptions, but a few of them are raised in specific conditions as well. More on that in a minute. All other exceptions inherit from the Exception class.

00:50 You have the concrete exceptions. These are the main exceptions you’ll encounter in Python, and you can also use them as base classes for your own exceptions.

00:58 Both of the errors encountered in the previous lesson were concrete exceptions. There’s also a group of exceptions known as OS exceptions. These exceptions inherit from OSError, and represent exceptions originating in your operating system with Python passing them along to you.

01:13 You’ll typically need to handle these exceptions and won’t be raising them directly. Finally, there’s a group of exceptions called warnings and they inherit from Warning. True to their name, they warn you about events or actions that could cause errors in the future.

01:28 Let’s look at the base classes in more detail. The BaseExceptionGroup can be used to create an exception group that wraps any exception, not just exceptions.

01:36 Inheriting from Exception. GeneratorExit is an exception that occurs when a generator or coroutine is closed.

01:43 A KeyboardInterrupt is raised when the user inputs the interrupt key combination, which is typically Ctrl-C. SystemExit can be triggered by calling the sys.exit() function within code, or can be raised directly by its name.

01:57 And of course, in addition to what you saw in the hierarchy diagram, Exception should be used as the base class for any exceptions that you define.

02:05 One more thing. Let’s address warnings. Distinct from other exceptions, warnings do not halt program execution. What they do is warn you about potential errors or unintended side effects.

02:18 And this gives you an opportunity to update your code before library authors introduce breaking changes, which would lead to errors.

02:25 And in the context of where your code is running, you usually have the option to suppress or filter warnings as well, effectively hiding them. And while you can do this and ignore them, it is best to follow their directions and update your code accordingly to avoid running into trouble further down the road.

02:42 You can read more about the different types of warnings you’ll find in the Python documentation. For now, why don’t you pop open the REPL and I’ll show you a brief example of a warning you can encounter using Python.

02:54 Open the REPL. This example uses the built-in calendar library. In Python 3.13, the title case January constant from that library is deprecated, meaning it’ll be removed in a future version of Python.

03:08 So if you import calendar

03:10 and access it, it still works: calendar.January and the output is the integer 1. But along with the output, you get a deprecation warning, letting you know that title case January is deprecated and you should be using uppercase JANUARY instead.

03:26 And when you encounter a simple deprecation warning like this, it’s always a good idea to address it right away. Alright, I think that’s enough theory. Coming up next, our tour of built-in exceptions begins with the humble SyntaxError.