{"id":2697,"date":"2025-03-28T07:02:23","date_gmt":"2025-03-28T07:02:23","guid":{"rendered":"https:\/\/mailitics.com\/index.php\/2025\/03\/28\/data-science-from-school-to-work-part-iii\/"},"modified":"2025-03-28T07:02:23","modified_gmt":"2025-03-28T07:02:23","slug":"data-science-from-school-to-work-part-iii","status":"publish","type":"post","link":"https:\/\/mailitics.com\/index.php\/2025\/03\/28\/data-science-from-school-to-work-part-iii\/","title":{"rendered":"Data Science: From School to Work, Part III"},"content":{"rendered":"

Data Science: From School to Work, Part III
\n \t

\n
<\/BR>
\n
\n \t

\n
<\/BR><\/p>\n

\n

Introduction<\/strong><\/h2>\n

Writing code is about solving problems, but not every problem is predictable. In the real world, your software will encounter unexpected situations: missing files, invalid user inputs, network timeouts, or even hardware failures. This is why handling errors isn\u2019t just a nice-to-have; it\u2019s a critical part of building robust and reliable applications for production.<\/p>\n

Imagine an e-commerce website. A customer places an order, but during the checkout process, a database connection issue occurs. Without proper Error Handling<\/a>, this issue could cause the application to crash, leaving the customer frustrated and the transaction incomplete. Worse, it might create inconsistent data, leading to even bigger problems down the line. Thus, error handling is a fundamental skill for any Python developer who wants to write code for production.<\/p>\n

However, good error handling also goes hand in hand with a good logging system. It\u2019s rare to have access to the console when the code is running in production. So there\u2019s no chance of your print being seen by anyone. To ensure that you can monitor your application and investigate any incidents, you need to set up a logging system. This is where the loguru<\/a> package comes into play, which I will introduce in this article.<\/p>\n

\n

I \u2013 How to handle Python errors?<\/strong><\/h2>\n

In this part I present the best practices of error handling in Python<\/a>, from try-except blocks and the use of raise<\/code> to the finally<\/code> <\/em>statement. These concepts will help you write cleaner, more maintainable code that is suitable for a production environment.<\/p>\n

\nThe <\/strong>try-expect<\/em><\/strong> blocks<\/strong>
\n<\/h3>\n

The try-except block is the main tool for handling errors in Python. It allows you to catch potential errors during code execution and prevent the program from crashing.<\/p>\n

def divide(a, b):\n\u00a0 try:\n\u00a0 \u00a0 return a \/ b\n\u00a0 except ZeroDivisionError:\n\u00a0 \u00a0 print(f\"Only Chuck Norris can divide by 0!\")<\/code><\/pre>\n
In this trivial function, the try-except block allows the error caused by a division by 0 to be intercepted. The code in the try block is executed, and if an error occurs, the except block checks whether it is a ZeroDivisionError<\/code> and print a message. But only this type of error is caught. For example, if b<\/em> is a string, an error occurs. To avoid this, you can add a TypeError<\/code>. So, it is important to test all possible errors.<\/p>\n
The function becomes:<\/p>\n
def divide(a, b):\n\u00a0 \u00a0 try:\n\u00a0 \u00a0 \u00a0 \u00a0 return a \/ b\n\u00a0 \u00a0 except ZeroDivisionError:\n\u00a0 \u00a0 \u00a0 \u00a0 print(f\"Only Chuck Norris can divide by 0!\")\n\u00a0 \u00a0 except TypeError:\n\u00a0 \u00a0 \u00a0 \u00a0 print(\"Do not compare apples and orange!\")<\/code><\/pre>\n
Raise an exception<\/strong><\/h3>\n
You can use the raise statement to manually raise an exception. This is useful if you want to report a user-defined error or impose a specific restriction on your code.<\/p>\n
def divide(a, b):\n\u00a0 \u00a0 if b == 0:\n\u00a0 \u00a0 \u00a0 \u00a0 raise ValueError(\"Only Chuck Norris can divide by 0!\")\n\u00a0 \u00a0 return a \/ b\n\n\ntry:\n\u00a0 \u00a0 result = divide(10, 0)\nexcept ValueError as e:\n\u00a0 \u00a0 print(f\"Error: {e}\")\nexcept TypeError:\n\u00a0 \u00a0 print(\"Do not compare apples and orange!\")<\/code><\/pre>\n
In this example, a ValueError<\/code> exception is triggered if the divisor is zero. In this way, you can explicitly control the error conditions. In the print function, the message will be \u201cError: Only Chuck Norris can divide by 0!<\/em>\u201c.<\/p>\n
Some of the most common exceptions<\/strong><\/h3>\n
ValueError<\/strong>: The type of a value is correct but its value is invalid.<\/p>\n
try:\n\u00a0 \u00a0 number = math.sqrt(-10)\nexcept ValueError:\n\u00a0 print(\"It's too complex to be real!\")<\/code><\/pre>\n
KeyError<\/strong>: Trying to access a key that doesn\u2019t exist in a dictionary.<\/p>\n
data = {\"name\": \"Alice\"}\ntry:\n\u00a0 \u00a0 age = data[\"age\"]\nexcept KeyError:\n\u00a0 \u00a0 print(\"Never ask a lady her age!\")<\/code><\/pre>\n
IndexError<\/strong>: Trying to access a non-existent index in a list.<\/p>\n
items = [1, 2, 3]\ntry:\n\u00a0 \u00a0 print(items[3])\nexcept IndexError:\n\u00a0 \u00a0 print(\"You forget that indexing starts at 0, don't you?\")<\/code><\/pre>\n
TypeError<\/strong>: Performing an operation on incompatible types.<\/p>\n
try:\n\u00a0 \u00a0 result = \"text\" + 5\nexcept TypeError:\n\u00a0 \u00a0 print(\"Do not compare apples and orange!\")<\/code><\/pre>\n
FileNotFoundError<\/strong>: Trying to open a non-existing file.<\/p>\n
try:\n\u00a0 \u00a0 with open(\"notexisting_file.txt\", \"r\") as file:\n\u00a0 \u00a0 \u00a0 \u00a0 content = file.read()\nexcept FileNotFoundError:\n\u00a0 \u00a0 print(\"Are you sure of your path?\")<\/code><\/pre>\n
Custom Error<\/strong>: You can trigger predefined exceptions or also define your own exception classes:<\/p>\n
class CustomError(Exception):\n\u00a0 \u00a0 pass\n\ntry:\n\u00a0 \u00a0 raise CustomError(\"This is a custom error\")\nexcept CustomError as e:\n\u00a0 \u00a0 print(f\"Catched error: {e}\")<\/code><\/pre>\n
\nClean with the <\/strong>finally <\/em><\/strong>statement<\/strong>
\n<\/h3>\n
The finally<\/code> block is executed in every case, regardless of whether the error has occurred or not. It is often used to perform cleanup actions, such as closing a connection to a database or releasing resources.<\/p>\n
import sqlite3\n\ntry:\n\u00a0 \u00a0 conn = sqlite3.connect(\"users_db.db\")\u00a0 # Connect to a database\n\u00a0 \u00a0 cursor = conn.cursor()\n\u00a0 \u00a0 cursor.execute(\"SELECT * FROM users\")\u00a0 # Execute a query\n\u00a0 \u00a0 results = cursor.fetchall()\u00a0 # Get result of the query\n\u00a0 \u00a0 print(results)\nexcept sqlite3.DatabaseError as e:\n\u00a0 \u00a0 print(\"Database error:\", e)\nfinally:\n\u00a0 \u00a0 print(\"Closing the database connection.\")\n\u00a0 \u00a0 if 'conn' in locals():\n\u00a0 \u00a0 \u00a0 \u00a0 conn.close()\u00a0 # Ensures the connection is closed<\/code><\/pre>\n
Best practices for error handling<\/strong><\/h3>\n
    \n
  1. \nCatch specific exceptions<\/strong>: Avoid using a generic except block without specifying an exception, as it may mask unexpected errors. Prefer specifying the exception:<\/li>\n<\/ol>\n
    # Bad practice\ntry:\n\u00a0 \u00a0 result = 10 \/ 0\nexcept Exception as e:\n\u00a0 \u00a0 print(f\"Error: {e}\")\n\n# Good practice\ntry:\n\u00a0 \u00a0 result = 10 \/ 0\nexcept ZeroDivisionError as e:\u00a0\n\u00a0 \u00a0 print(f\"Error: {e}\")<\/code><\/pre>\n
      \n
    1. \nProvide explicit messages<\/strong>: Add clear and descriptive messages when raising or handling exceptions.<\/li>\n
    2. \nAvoid silent failures<\/strong>: If you catch an exception, ensure it is logged or re-raised so it doesn\u2019t go unnoticed.<\/li>\n<\/ol>\n
      import logging\n\nlogging.basicConfig(level=logging.ERROR)\n\ntry:\n\u00a0 \u00a0 result = 10 \/ 0\nexcept ZeroDivisionError:\n\u00a0 \u00a0 logging.error(\"Division by zero detected.\")<\/code><\/pre>\n
        \n
      1. \nUse <\/strong>else<\/code> and <\/strong>finally<\/code> blocks<\/strong>: The else<\/code> block runs only if no exception is raised in the try<\/code> block.<\/li>\n<\/ol>\n
        try:\n\u00a0 \u00a0 result = 10 \/ 2\nexcept ZeroDivisionError:\n\u00a0 \u00a0 logging.error(\"Division by zero detected.\")\nelse:\n\u00a0 \u00a0 logging.info(f\"Success: {result}\")\nfinally:\n\u00a0 \u00a0 logging.info(\"End of processing.\")<\/code><\/pre>\n
        \n
        II \u2013 How to handle Python logs?<\/strong><\/h2>\n
        Good error-handling is one thing, but if no one knows that an error has occurred, the whole point is lost. As explained in the introduction, the monitor is rarely consulted or even seen when a program is running in production. No one will see print. Therefore, good error handling must be accompanied by a good logging system.<\/p>\n
        What are logs?<\/strong><\/h3>\n
        Logs are records of messages generated by a program to track the events that occur during its execution. These messages may contain information about errors, warnings, successful actions, process milestones or other relevant events. Logs are essential for debugging, tracking performance and monitoring the health of an application. They allow developers to understand what is going on in a program without having to interrupt its execution, making it easier to solve problems and continuously improve the software.<\/p>\n
        The loguru package<\/strong><\/h3>\n
        Python already has a native logging package: logging. But we prefer the loguru package, which is much simpler to use and easier to configure. In fact, complete output formatting is already preconfigured.<\/p>\n
        from loguru import logger\nlogger.debug(\"A pretty debug message!\")<\/code><\/pre>\n
        \"\"
        Image from author.<\/figcaption><\/figure>\n
        All the important elements are included directly in the message:<\/p>\n