vincentbernat
commented
1 year ago Moreover, the exceptions are fatal as they call sys.exit(1).
Closed daemonkeeper closed 1 year ago
vincentbernat
commented
1 year ago Moreover, the exceptions are fatal as they call sys.exit(1).
mpenning
commented
1 year ago Moreover, the exceptions are fatal as they call
sys.exit(1).
I want unhandled exceptions to be fatal.
daemonkeeper
commented
1 year ago Thanks for the quick fix. I've tested your change and now I do get the exceptions raised back into my code, allowing me to handle them properly there. Thanks.
mpenning
commented
1 year ago NOTE I also added a unit test for this case at git commit hash 07ff028d14fcf603712c8556bf2f324466d08782... see testParse_invalid_config() in test_CiscoConfParse.py
mpenning
commented
1 year ago Documenting a complete try / except / finally example under ciscoconfparse version 1.6.44...
@logger.catch(reraise=False), loguru swallows the error.
try block never sees a problem and executes as if no error happened.except block does NOT run in this case.@logger.catch(reraise=True)
try block catches the NotImplementedError() during the reraiseexcept block runs.reraise=True)In both reraise cases, logger.catch() sends loguru error output to the terminal session. The only difference is whether the except block runs.
# filename is 'try_test.py'
from loguru import logger
@logger.catch(reraise=True)
def simulate_ccp_function():
raise NotImplementedError()
def user_function():
try:
print("'try' Before calling simulate_ccp_function()")
simulate_ccp_function()
print(" 'try' After calling simulate_ccp_function()")
except:
print(" 'except' was executed")
finally:
print(" 'finally' was executed")
if __name__=="__main__":
user_function()When that script runs, we get the following output...
mpenning
commented
1 year ago Also see the question I asked about try / except usage in delgan/loguru...
Your code very much makes it impossible to use it as a library. You intercept exceptions without ever raising them again, and sink them into the wrapped loguru handler code for display. Unfortunately not everyone wants to see a fancy stack trace upon an exception on stderr (or use loguru on that matter), and instead might prefer to raise them to calling code, in order to properly handle it there (and/or use my logging system of choice to log it).
For example:
never hits in my exception handler, because you catch and sink your ValueException into loguru:
Since you unambiguously always call
configure_loguru()e.g; in ciscoconfparse.py) you may want to give the consumers of your classes a way to intercept and configure the behavior.I am able to disable the fancy stack trace output by calling
ccp_logger_control(action="disable"), but that won't raise them back to my code because of the missing 'reraise' when initializing the loguru logger. Moreover, I'd argue re-raising exceptions should be the default anyway.As a strech goal you may want to consider letting users set their own (non-loguru) handlers to catch your log output and properly sink it wherever my system wants.