Robustness: Defensive NoneType handling during recordset or connection iteration

[UsmanGhias]

First, thank you so much for maintaining loguru. It's an indispensable tool in our stack, and I really appreciate the care put into its design.

Summary

While working with custom sinks and handling edge cases where a record or connection object might be uninitialized or return None, I noticed that certain serialization or iteration flows can trigger an unhandled AttributeError. Adding a light defensive check for NoneType would make custom sink integrations a bit more resilient and yield a clearer error message.

Environment

• Python version: 3.12.1
• Operating System: Ubuntu 22.04
• Loguru version: 0.7.2 (current main)

Steps to Reproduce

from loguru import logger

def awkward_sink(message):
    # Simulated edge case where record metadata might be empty/None
    record = message.record
    record["extra"] = None
    
    # Attempting to iterate or serialize when an inner attribute is None
    for _ in record["extra"]:
        pass

logger.add(awkward_sink)
logger.info("Triggering sink")

Expected Behavior

Loguru handles the edge case gracefully or raises a descriptive, context-aware error explaining that the target object is uninitialized or None.

Actual Behavior

An unhandled AttributeError: 'NoneType' object is not iterable bubbles up from deep within the handling/formatting sequence rather than a clean loguru-specific error.

Happy to submit a quick PR for this if the maintainers are open to it!

[Delgan]

Hello @UsmanGhias.

Do you have any more specific examples that cause record[“extra”] to be None? Is this due to Loguru's integration with the standard logging library, or something else?

There isn't really any "defensive check" that Loguru can make, except verifying the type at runtime. But Loguru should not attempt to validate or sanitize arbitrary objects. Since record["extra"] is not expected du be None, this means there is an upstream problem that should be fixed, and maybe a type checker shine there.