[Bug/Enhancement] logger.catch(level=...) incorrectly rendered when using standard logging library levels
When using logger.catch with error codes from the standard logging library, the log level will be rendered incorrectly as below:
from logging import CRITICAL
from loguru import logger
@logger.catch(level=CRITICAL)
def error():
raise Exception
error()
2024-01-01 20:38:27.032 | Level 50 | __main__:<module>:11 - An error has been caught in function '<module>', process 'MainProcess' (80296), thread 'MainThread' (7921619712):
Traceback (most recent call last):
> File "/Users/jimmy/Desktop/dev/Enigma/test.py", line 11, in <module>
error()
└ <function error at 0x103c52d40>
File "/Users/jimmy/Desktop/dev/Enigma/test.py", line 8, in error
raise Exception
Exception
This behaviour however is fixed when passing a string in logger.catch, as the code snippets below:
from loguru import logger
@logger.catch(level="CRITICAL")
def error():
raise Exception
error()
2024-01-01 20:39:46.068 | CRITICAL | __main__:<module>:11 - An error has been caught in function '<module>', process 'MainProcess' (80376), thread 'MainThread' (7921619712):
Traceback (most recent call last):
> File "/Users/jimmy/Desktop/dev/Enigma/test.py", line 11, in <module>
error()
└ <function error at 0x1050f6d40>
File "/Users/jimmy/Desktop/dev/Enigma/test.py", line 8, in error
raise Exception
Exception
Is this an intended feature or a bug? Many thanks for the answer.
Hi @iuyunn.
Although this behavior is somewhat unpleasant, this is technically the expected behavior.
The value of logging.CRITICAL is an integer, but contrary to the standard logging library, Loguru does not map integer values back to a level name. This is because multiple levels can share the same severity value, therefore it would not be possible to resolve them unambiguously.
For this reason, levels within Loguru are uniquely identified by they name. When an integer is used in logger.log() or logger.catch(), Loguru considers it to be an "anonymous level", and will display "Level X" instead.