Logger.catch

[ChristianSauer]

[ChristianSauer]

Logger catch is very useful, but it is problematic in conjunction with click, especially the error code will always be 0, even if there was an exception.

e.g.

@click.group()
def cli():
    pass

@cli.command('setup')
def cli_setup():
    raise Exception("boom!")

@logger.catch(reraise=True)  
def main():
    cli()

If you execute python file.py setup this will set the exit code to 0, expected would be 1

[Delgan]

@ChristianSauer I assume main() is missing at the end of your code snippet, right?

Because on my computer, it's working fine, the exit code is 1 thanks to the reraise=True argument.

[ChristianSauer]

@Delgan yes, you are correct.
And yes, reraise works as expected. The problem is that now the stacktrace is doubled, first in the log, then as the last output of the program. Its just ugly and complicated when you have a long stacktrace.
i would suggest adding a small sentence to the doc warning that without reraise, the exit code will be 0.

[Delgan]

I do agree this is a bit inconvenient. Actually, I just realized that in most of my scripts, I replaced @logger.catch with another snippet because of that.

try:
    main()
except Exception as e:
    logger.opt(exception=True).critical(str(e))
    sys.exit(1)

That's too bad. It means @catch is not used while it's one of the use case where it should shine.

I'm thinking of adding a new parameter to catch() to circumvent this problem. For example, logger.catch(exit=True) could automatically call sys.exit(1) if an exception is caught. Alternatively, a parameter accepting a function like onerror=lambda exc: sys.exit(1) would provide more flexibility.

[ChristianSauer]

Thats good news, thanks!
I would probably use the onerror variant, cli programs often use different exit codes for different failure modes so some flexibility would open up a lot of use cases.

[Delgan]

Done. The new onerror argument will be available in the next release. Thanks for your input! 😉