Custom Exceptions and Assertions

First, let's get the basics straight. In Python, an exception is just a fancy word for an error that occurs while your program is running. When a function tries to divide by zero, Python raises a ZeroDivisionError. When you try to open a file that doesn't exist, it raises a FileNotFoundError. These are built-in exceptions—the standard set of problems that Python knows about. But what happens when your own code encounters a problem that those built-in errors don't cover? For example, imagine you're writing a banking app. A user tries to withdraw more money than they have in their account. There's no built-in InsufficientFundsError. So, you need to invent one. That's a custom exception.

To create a custom exception, you define a new class that inherits from Python's Exception class (or any of its subclasses). Here's the simplest possible example:

class InsufficientFundsError(Exception): pass

The word 'class' is Python's way of defining a new type of thing. By putting 'Exception' in parentheses after the name of your new class, you tell Python: 'This new error is a special kind of Exception, so it behaves like one.' The 'pass' keyword just means 'do nothing extra right now.' Once you've defined this class, you can use the 'raise' statement to trigger it:

raise InsufficientFundsError('Your balance is too low.')

When this line runs, Python stops the normal flow of your program and looks for a handler—a 'try-except' block that knows how to deal with this specific error. If no handler catches it, the program crashes. But if you wrote a handler like:

try: withdraw(account, 500) except InsufficientFundsError as e: print(f'Transaction failed: {e}')

...then your program can respond gracefully, perhaps by asking the user to try a smaller amount. The goal of custom exceptions is to make your code more organised and easier to debug. Instead of a vague 'something went wrong' message, you get a specific error type that tells you, and anyone reading your code, exactly what the problem is.

Now, let's talk about assertions. An assertion is a more aggressive form of checking. It's like a checkpoint that says, 'This condition must be true, or everything I'm about to do is meaningless.' In Python, you write an assertion using the 'assert' keyword:

assert account_balance >= withdrawal_amount, 'Balance cannot be negative after withdrawal'

If the condition (account_balance >= withdrawal_amount) is True, nothing happens—Python just moves on. But if it's False, Python raises an AssertionError and prints the optional message you provided. The key difference between an assertion and a regular 'if' statement is that assertions are intended for catching programmer mistakes during development, not for handling predictable runtime errors. You use them to check assumptions that you believe should always hold true—like 'this list isn't empty' or 'this parameter has a valid value.'

Why would you use an assertion instead of an 'if' statement? Because you can disable all assertions globally when you run Python with the '-O' (optimise) flag. That means you can leave assertions in your code as a safety net during testing, but turn them off for a production release where you don't want the overhead of extra checks. A regular 'if' statement can't be turned off—it always runs. So, use assertions for conditions that should never happen if your code is correct, and use custom exceptions for situations that might reasonably occur (like a user typing invalid input).

Let's solidify this with a real coding example. Suppose you're writing a function that calculates the average of a list of numbers. You might add an assertion that the list is not empty:

def average(numbers): assert len(numbers) > 0, 'numbers list must not be empty' return sum(numbers) / len(numbers)

If someone mistakenly calls average([]), Python will crash with an AssertionError, alerting you to the bug during development. But if you expect that sometimes users will legitimately pass an empty list, you should instead raise a custom exception (or return a special value) and handle it in a try-except block. The choice depends on your design: assertions for programmer errors, custom exceptions for anticipated runtime problems.

Finally, a word on exception hierarchies. You can make your custom exceptions more sophisticated by creating a base exception for your entire application and then subclasses for more specific errors. For example:

class BankError(Exception): pass class InsufficientFundsError(BankError): pass class AccountNotFoundError(BankError): pass

Now, any except clause that catches BankError will also catch InsufficientFundsError and AccountNotFoundError. This lets you handle groups of related errors with a single handler, while still being able to catch each specific error individually. This is one of the most powerful features of custom exceptions—you can build a error-handling hierarchy that mirrors your application's domain logic.

Imagine you work for a small e-commerce company that sells handmade furniture. The company's IT department manages a Python application that processes customer orders. One day, a customer tries to place an order for a table that's been discontinued. The current code just crashes with a generic 'KeyError' because the product ID isn't in the database. The support team gets a confused call, and no one knows exactly what went wrong.

Your job is to fix this. You decide to create a set of custom exceptions for the ordering system. You start by defining:

class OrderProcessingError(Exception): pass class ProductNotFoundError(OrderProcessingError): pass class OutOfStockError(OrderProcessingError): pass class InvalidQuantityError(OrderProcessingError): pass

Now, when the database lookup fails, instead of letting Python raise a generic KeyError, you write:

if product_id not in product_database: raise ProductNotFoundError(f'Product {product_id} not found')

This tells everyone exactly what went wrong: a product was requested that doesn't exist. Later, when someone tries to order a quantity of -3, you can raise InvalidQuantityError. The support team can now see clear error messages in logs, and you can write a single except block that catches OrderProcessingError and sends a polite email to the customer.

Then, you decide to add assertions to check your own assumptions. In the function that calculates shipping costs, you add:

def calculate_shipping(order_weight_kg): assert order_weight_kg > 0, 'Order weight must be positive' # ... calculate shipping

This assertion catches a bug where a developer accidentally passed a negative weight. It's not a customer-facing problem yet—it's a programming mistake you want to catch early. During testing, if an assertion fires, you immediately know to fix the calling code. When you deploy to production, you might turn off assertions with the '-O' flag to avoid the performance cost, but your custom exceptions (ProductNotFoundError, etc.) stay active because they handle real user-facing errors.

The real-world routine of an IT professional involves reading error logs from production systems. When you see a generic 'Exception' logged, you have no clue what went wrong. But when you see 'ProductNotFoundError: product id 12345', you know exactly where to start investigating. Custom exceptions transform your logs from noise into actionable intelligence.

In a larger team, custom exceptions also serve as a contract between developers. If you write a library function that raises InsufficientFundsError, other developers know they must either handle it or let it propagate. The exception hierarchy tells them: 'If you catch OrderProcessingError, you'll cover all order-related errors.' This reduces bugs because teammates don't accidentally catch a generic Exception and swallow a completely unrelated error.