Typeerror exceptions must derive from baseexception

Are you having Typeerror exceptions must derive from baseexception error while raising class with raise keyword?

Well, this error typically occurs when we raise an exception that is not an instance of a class which inherits from the built-in Exception class.

Along with this guide, we will explore why this error occurs and provide you with practical solutions to help you fix it.

So, let’s proceed in and learn how to handle this error like a pro!

Why Typeerror exceptions must derive from baseexception occurs?

The TypeError: exceptions must derive from BaseException occurs when we try to raise an error without passing a class that inherits from the BaseException class.

Let’s say we want to raise an error when the sample variable is not an int as follows:

sample = 'itsourcecode'

if type(sample) is not int:
    raise "Error! x must be a int"

Since the raise keyword above is not followed with a class that inherits from the BaseException class, Python will raise the following error:

Traceback (most recent call last):
  File "C:\Users\Windows\PycharmProjects\pythonProject1\main.py", line 4, in <module>
    raise "Error! x must be a int"
TypeError: exceptions must derive from BaseException

How to fix exceptions must derive from baseexception

Fixing this error really depends on the nature of the error wherein it depends on the exception class provided by Python.

Suppose we consider the given example above which raise an error. This time we will use Typeerror class which looks like this:

sample = 'itsourcecode'

if type(sample) is not int:
    raise TypeError("Error! sample must be an int")

Output:

Traceback (most recent call last):
  File "C:\Users\Windows\PycharmProjects\pythonProject1\main.py", line 4, in <module>
    raise TypeError("Error! sample must be an int")
TypeError: Error! sample must be an int

You can also use other common exception classes such as AssertionError, ValueError, or RuntimeError.

Apparently, you can utilize other exception classes as shown in this Exception hierarchy.

Also, we can define custom exception classes in Python.

Hierarchy of the built-in Exception classes in Python

This time we can define our own custom exception class in Python.

To accomplish so, we must create a class that extends from the Exception class.

Assuming we want to create an exception class named MyException.

Here’s how to do it:

class MyException(Exception):
    def __init__(self, message):
        self.message = message
    def __str__(self):
        return self.message

After we defined, we can now use the class when raising an error as follows:

class MyException(Exception):
    def __init__(self, message):
        self.message = message

    def __str__(self):
        return self.message

sample = 'itsourcecode'

if type(sample) is not int:
    raise MyException("Error! sample must be an int")

Though creating your own exception classes will extend the complexity of your code.

So it is recommended to only create a customized exception class when the built-in ones don’t cover the error needed to raise.

Anyhow, if you are finding solutions to some errors you might encounter we also have TypeError can’t concat str to bytes.

Conclusion

In conclusion, the TypeError: exceptions must derive from BaseException occurs when we attempt to raise an error without defining the exception class.

To solve this error, we need to pass a built-in or custom exception class that’s relevant to the error we want to raise.

Thank you for reading!

Python TypeError debugging checklist

• Read the full traceback. The bottom line is the error type + message. The line above shows the exact code that triggered it.
• Print types. Insert print(type(x), type(y)) before the error line to see what Python actually has.
• Use isinstance. Guard code with if isinstance(x, expected_type):.
• Type hints + mypy. Adding x: int lets mypy catch mismatches before you run the code.
• Break into a debugger. Insert breakpoint() before the failing line and inspect variables live.

Common root causes across all TypeError variants

• Silent None returns. A function that should have returned a value returned None instead.
• Mixing types across function boundaries. Legacy code passing str where int is expected (or vice versa).
• Shadowed builtins. Local variable named list, dict, set overriding the built-in.
• Optional[T] not handled. Callers not accounting for the None case.
• Third-party library API drift. New version renamed a kwarg or changed a return type.

Modern tooling to prevent TypeError

• Type hints (PEP 484+). Optional[X], Union[X,Y], List[T] make expected types explicit.
• mypy or Pyright. Runs your codebase through a type checker before you run it.
• Ruff. Fast linter that catches many TypeError-adjacent bugs.
• pydantic v2. Runtime validation with the same syntax as static types.
• pytest fixtures. Test each function with edge-case inputs to catch TypeError paths early.

Glay Eliver

Programmer & Technical Writer at PIES IT Solution

Glay Eliver is a programmer and writer at PIES IT Solution, author of over 600 tutorials at itsourcecode.com. Specializes in JavaScript tutorials, Microsoft Office how-tos (Excel, Word, PowerPoint), and Python error debugging covering ImportError, TypeError, AttributeError, ModuleNotFoundError, and JavaScript ReferenceError. Authored several of the site’s highest-traffic Excel and MS Office reference articles.

Expertise: JavaScript · MS Excel · MS Word · MS PowerPoint · Python · Python ImportError · Python TypeError · Python AttributeError · ModuleNotFoundError · JavaScript ReferenceError · Pygame
 · View all posts by Glay Eliver →