Suppress logging stack trace on stable build for HomeAssistantError

[jbouwh]

Proposed change

Suppress stack traces on logs raised with HomeAssistantError on stable versions of HomeAssistant and when debug logging is abled (for a specific logger).

Rationale

HomeAssistantError and its subclasses are expected errors which means a stack trace is not warranted. Printing a stack trace is still very helpful during development though. The solution in the PR avoids spamming users with stack traces, while also not obstructing development.

We make it possible to enable logging stack trace for HomeAssistantError also on stable builds when debug level is supported by the logger.

Architectural discussion: home-assistant/architecture#986

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request: Add blogpost - Suppress logging stack trace HomeAssistantError on stable builds developers.home-assistant#1947

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[emontnemery]

LGTM, thanks @jbouwh 👍

[emontnemery]

This is quite a big change, before we merge I'd like:

• A second opinion
• If the change is deemed good to go, a blog post introducing the change

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

[jbouwh]

Thnx @MartinHjelmare , I'll prepare a blog post

[jbouwh]

Shouldn't we catch these instead where they end up as traces?? If we print traces for them it means we are not expecting them.

That is an alternative approach. We catch the expected errors in homeassistant/components/websocket_api/commands.py where the message text is send to the frontend. The traces though are assumed to be of interest for development only. For normal users the traces will spam the logs.

[elupus]

If we have places where we print traces for these exceptions, that is a bug. We should find those places and fix them, not hide it globally.

[elupus]

Secondly, if we are interested in the traces we could print traces if debug level logging is on for that specific location where we caught the exception. Again this need to be done where we catch the exception.

[jbouwh]

If we have places where we print traces for these exceptions, that is a bug. We should find those places and fix them, not hide it globally.

Just to be clear: This PR is not effecting stack traces for unexpected exceptions.

[elupus]

Right, and i say that any place that prints traces for these exceptions are faulty.

[jbouwh]

Right, and i say that any place that prints traces for these exceptions are faulty.

Okay, all we are effectively doing here is suppressing track prints on known catched errors. All other errors can be assumed caused by bugs, will have a stack trace and should be fixed indeed.

[jbouwh]

Secondly, to still allow developers to solve caught exceptions, stack traces are still unfiltered for know errors.

[MartinHjelmare]

Drafting so we make sure we're aligned on the next step before going ahead.

[emontnemery]

The implementation is changing, and there's an open architecture issue -> I requested a new review from myself and @MartinHjelmare

[jbouwh]

Superseeded by #102410