There are a couple of posts on this but all seem to address the cause, not handling the exception.
Use case : I have an integration that throws random exceptions but ultimately works. The integration developer is unresponsive. When the integration doesn’t handle the exception my whole automation fails as subsequent steps don’t occur.
Suggestion : Add option to automations “What to do on error” with options “Stop Execution”, “Continue to next step”
tom_l
April 4, 2022, 12:45am
2
You can already do this now by putting the likely to fail actions in a script and calling it using the script.turn_on
service rather than directly:
https://www.home-assistant.io/integrations/script/#waiting-for-script-to-complete
Ah, hadn’t seen/processed this feature. I’ll go this route as it’s a nice work-around, but still ultimately a work-around.
tom_l
April 4, 2022, 1:41am
4
Not really. Having a faulty integration is the problem that should be fixed.
frenck
(Franck Nijhof)
April 14, 2022, 5:18pm
5
This is implemented in:
home-assistant:dev
← home-assistant:frenck-2022-0870
opened 07:58PM - 13 Apr 22 UTC
<!--
You are amazing! Thanks for contributing to our project!
Please, DO N… OT DELETE ANY TEXT from this template! (unless instructed).
-->
## Proposed change
<!--
Describe the big picture of your changes here to communicate to the
maintainers why we should accept this pull request. If it fixes a bug
or resolves a feature request, be sure to link to that issue in the
additional information section.
-->
Ideally, services throw errors when something goes wrong. Like, anything at all. We do a review on this nowadays to make everything more consistent.
However, many services don't do that (e.g., when a device is offline, or on API errors), because it stops scripts and automation sequences. (And users sometimes raise issues for those occurrences, while actually correct).
So that means we have a gap now. A user may want to ignore an error... and might not care if that single step failed or not.
This PR introduces: `continue_on_error`.
It can be set on each step in a script sequence and continues the sequence if the error is reasonable to handle. For example, broken templates and not handled errors by integration libraries (for example), are still raised, even when this option is used.
```yaml
action:
- alias: "If this one fails..."
continue_on_error: true
service: notify.super_unreliable_service_provider
data:
message: "I'm going to error out..."
- alias: "I'm still OK! :)"
service: persistent_notification.create
data:
title: "Hi there!"
message: "I'm fine..."
```
The name `continue_on_error` has been chosen to be consistent with the existing `continue_on_timeout` we use in other places.
## Type of change
<!--
What type of change does your PR introduce to Home Assistant?
NOTE: Please, check only 1! box!
If your PR requires multiple boxes to be checked, you'll most likely need to
split it into multiple PRs. This makes things easier and faster to code review.
-->
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [x] New feature (which adds functionality to an existing integration)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Additional information
<!--
Details are important, and help maintainers processing your PR.
Please be sure to fill out additional details, if applicable.
-->
- This PR fixes or closes issue: fixes #
- This PR is related to issue:
- Link to documentation pull request: https://github.com/home-assistant/home-assistant.io/pull/22390
## Checklist
<!--
Put an `x` in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to ask.
We're here to help! This is simply a reminder of what we are going to look
for before merging your code.
-->
- [x] The code change is tested and works locally.
- [x] Local tests pass. **Your PR cannot be merged unless tests pass**
- [x] There is no commented out code in this PR.
- [x] I have followed the [development checklist][dev-checklist]
- [x] The code has been formatted using Black (`black --fast homeassistant tests`)
- [x] 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][docs-repository]
If the code communicates with devices, web services, or third-party tools:
- [ ] The [manifest file][manifest-docs] 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`.
The integration reached or maintains the following [Integration Quality Scale][quality-scale]:
<!--
The Integration Quality Scale scores an integration on the code quality
and user experience. Each level of the quality scale consists of a list
of requirements. We highly recommend getting your integration scored!
-->
- [x] No score or internal
- [ ] 🥈 Silver
- [ ] 🥇 Gold
- [ ] 🏆 Platinum
<!--
This project is very active and we have a high turnover of pull requests.
Unfortunately, the number of incoming pull requests is higher than what our
reviewers can review and merge so there is a long backlog of pull requests
waiting for review. You can help here!
By reviewing another pull request, you will help raise the code quality of
that pull request and the final review will be faster. This way the general
pace of pull request reviews will go up and your wait time will go down.
When picking a pull request to review, try to choose one that hasn't yet
been reviewed.
Thanks for helping out!
-->
To help with the load of incoming pull requests:
- [x] I have reviewed two other [open pull requests][prs] in this repository.
[prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone+-status%3Afailure
<!--
Thank you for contributing <3
Below, some useful links you could explore:
-->
[dev-checklist]: https://developers.home-assistant.io/docs/en/development_checklist.html
[manifest-docs]: https://developers.home-assistant.io/docs/en/creating_integration_manifest.html
[quality-scale]: https://developers.home-assistant.io/docs/en/next/integration_quality_scale_index.html
[docs-repository]: https://github.com/home-assistant/home-assistant.io
Should be part of Home Assistant 2022.5
2 Likes
tom_l
April 14, 2022, 5:39pm
6
Nice. Would it be possible to apply it to all actions in a sequence rather than having to specify it for each one?
frenck
(Franck Nijhof)
April 14, 2022, 5:44pm
7
Yes, but you have to wrap it in another action (e.g. any action that accepts another sequence) and next you can set it on that one. Please note, that in that case, that subsequence will stop half way if one of those action nodes fails)
jemenake
(Joe)
January 17, 2023, 4:58am
8
“Ignore” an error is one element from the set of possible ways to handle and error, so I’d argue that there’s still a case for implementing OP’s suggestion. For example, the user might want to be alerted that the automation failed.
I ran into this need when I had an automation that snapshotted the states of a bunch of my lights when I left my house (and then turned them off) so that I could restore the scene when I returned. Problem was: the entities that the scene records are manually entered, and one of my entity names got changed.
This broke the whole leaving automation. HA was never actually turning my lights off after I left and restoring them when I returned. They were just left on the whole time. So, it would have been nice if there were some kind of on-error action (like pushing a notification to a voice assistant or my phone).
It might also be worthwhile to allow for a more global error handler, like a notification of any script fails, or if any automation fails, to save people from having to create the same error handler for each automation.
As I think about this more, since this info is only of use to the person who is configuring HA, maybe it could just be in the Developer Tools, where we could set a service call to make and then checkboxes for which errors types (scripts, automations, Zwave, Zigbee, etc) we want to be notified about.
BB9
(BB8)
January 18, 2023, 5:40pm
9
Would this be applicable to a TTS script to handle devices that aren’t available?
If so, how?
I tried adding “continue_on_error: true” to the script but it still wouldn’t work when a device wasn’t available.
parautenbach
(Pieter Rautenbach)
January 18, 2023, 8:08pm
10
jemenake:
It might also be worthwhile to allow for a more global error handler, like a notification of any script fails, or if any automation fails, to save people from having to create the same error handler for each automation.
You can go even further and react to any error however you like.