You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The python standard library logger swallows basically any error in logging, so logging errors don't interrupt otherwise working code. This guards against user error:
$ python <<EOF
import logging
logging.error("%d", None)
print("CONTINUE PAST LOGGING ERROR")
EOF
--- Logging error ---
Traceback (most recent call last):
File "/Users/avigil/.pyenv/versions/3.12.2/lib/python3.12/logging/__init__.py", line 1160, in emit
msg = self.format(record)
^^^^^^^^^^^^^^^^^^^
File "/Users/avigil/.pyenv/versions/3.12.2/lib/python3.12/logging/__init__.py", line 999, in format
return fmt.format(record)
^^^^^^^^^^^^^^^^^^
File "/Users/avigil/.pyenv/versions/3.12.2/lib/python3.12/logging/__init__.py", line 703, in format
record.message = record.getMessage()
^^^^^^^^^^^^^^^^^^^
File "/Users/avigil/.pyenv/versions/3.12.2/lib/python3.12/logging/__init__.py", line 392, in getMessage
msg = msg % self.args
~~~~^~~~~~~~~~~
TypeError: %d format: a real number is required, not NoneType
Call stack:
File "<stdin>", line 2, in <module>
Message: '%d'
Arguments: (None,)
CONTINUE PAST LOGGING ERROR
Note that the print in the above code gets executed despite the incorrect format string in the logging call above it.
It looks like structlog is less permissive:
$ python <<EOF
import structlog
structlog.get_logger().error("%d", None)
print("CONTINUE PAST LOGGING ERROR")
EOF
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
File "/Users/avigil/.pyenv/versions/structlog/lib/python3.12/site-packages/structlog/_native.py", line 146, in meth
return self._proxy_to_logger(name, event % args, **kw)
~~~~~~^~~~~~
TypeError: %d format: a real number is required, not NoneType
Note that unlike in the first example, the formatting TypeError in structlog gets raised and stops execution of the script so the final print is never run.
Would be nice if structlog behaved similarly to the standard library in this case, catching silly formatting errors coming from the user so they get logged somewhere but don't actually kill the running code.
The python standard library logger swallows basically any error in logging, so logging errors don't interrupt otherwise working code. This guards against user error:
Note that the
print
in the above code gets executed despite the incorrect format string in the logging call above it.It looks like structlog is less permissive:
Note that unlike in the first example, the formatting TypeError in structlog gets raised and stops execution of the script so the final print is never run.
Would be nice if
structlog
behaved similarly to the standard library in this case, catching silly formatting errors coming from the user so they get logged somewhere but don't actually kill the running code.environment:
The text was updated successfully, but these errors were encountered: