Add tracebacks to errors in CLI runs

[lrcouto]

Description

Fixes #4073

Development notes

Developer Certificate of Origin

We need all contributions to comply with the Developer Certificate of Origin (DCO). All commits must be signed off by including a Signed-off-by line in the commit message. See our wiki for guidance.

If your PR is blocked due to unsigned commits, then you must follow the instructions under "Rebase the branch" on the GitHub Checks page for your PR. This will retroactively add the sign-off to all unsigned commits and allow the DCO check to pass.

Checklist

• Read the contributing guidelines
• Signed off each commit with a Developer Certificate of Origin (DCO)
• Opened this PR as a 'Draft Pull Request' if it is work-in-progress
• Updated the documentation to reflect the code changes
• Added a description of this change in the RELEASE.md file
• Added tests to cover my changes
• Checked if this change will affect Kedro-Viz, and if so, communicated that with the Viz team

[deepyaman]

This message was introduced in 0.19.7; however, if we want to spit out the full trace, why is this necessary? Why can't you just doing something like

            self._cli_hook_manager.hook.after_command_run(
                project_metadata=self._metadata, command_args=args, exit_code=1
            )
            hook_called = True
            raise

?

This would be closer to the previous behavior.

In case you're unsure, your finally block will still be called:

>>> try:
...    print("do or do not")
...    raise Exception("oh no")
... except Exception as exc:
...    print("there is no try")
...    raise
... finally:
...    print("rip")
... 
do or do not
there is no try
rip
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
Exception: oh no
>>> 

[lrcouto]

That does output the stack trace but IMO is not as aesthetically nice. This is what it looks like using raise:

This is what it looks like using traceback.format_exc

The content of the trace is the same, but I think the second is easier to read.

[lrcouto]

Another option would be using the rich console traceback, but that would require importing rich.

[deepyaman]

Another option would be using the rich console traceback, but that would require importing rich.

I'm not sure if this is what you mean, but you get the Rich traceback as long as Rich is installed—you don't need to change the code.

In fact, one downside of catching and printing the formatted exception yourself is that you don't get the Rich traceback.

[lrcouto]

Without manually logging formatted exception and just using raise, it looks like the first image.

[merelcht]

I prefer the solution @deepyaman proposes. I've compared that with how it looks in 0.19.6 and it's exactly the same. I wouldn't worry too much about the formatting.

Side note: I don't know what's going on with the rich formatting. I used to have logs formatted like in the ticket description with the rectangle around them (#4073), but now I'm not seeing that.. If it's an issue in general I'd suggest tackling that separately.

[merelcht]

I wonder if #3682 has changed stuff.. I noticed that even if I use the default rich handler it doesn't pick it up in the catalog messages.

[lrcouto]

I've also noticed that our little hack of uninstalling rich and downgrading cookiecutter does not work anymore. I can take a look at that.

[noklam]

@merelcht #3682 shouldn't change this as it targets at two very specific log message with rich markup.

[deepyaman]

LGTM, thanks for updating!

[merelcht]

LGTM!