#Common problems: Continue on error

1 messages · Page 1 of 1 (latest)

frosty bridge
#

So, do you have a suggestion?

#

Is the problem in that example that the service handler incorrectly let's errors bubble up instead of catching and reraising as HomeAssistantError?

#

If that's the problem, I don't see why the script call_service action can't catch errors other than HomeAssistantError log/report it and allow script execution to continue

cold palm
#

I'm not really sure. Personally, I'd expect any action error to continue_on_error. Even errors that slip through miss configurations

#

I've just noticed a large influx of people creating continue_on_error issues

#

Here's a list of issues essentially exposed by it moving to the UI

frosty bridge
#

What do you mean by "configuration error"? Do you mean the service call fails because of schema error?

#

I think it's reasonable to not continue if we fail schema validation TBH

#

But I can see how it could make sense to catch unexpected exceptions in the call_service action handler, because it's a very common issue that service handlers don't catch all errors from the library.

cold palm
cold palm
#

FYI these issues have existed for some time, and I'm pretty sure there's been past issues about this as well.

jagged juniper
#

Error in this regard is when an action (service) completly fails to be called, not if it's configuration is incorrect

frosty bridge
#

well, it DOES fail to be called if the configuration can't be parsed 🙂

#

but yes, I also think it's a bit much to continue execution in such case

cold palm
#

I'm just raising the conversation because Joost asked me to after my comments in #the-murder-roost

#

the TLDR of my comments in #the-murder-roost are: Are we sure bringing continue on error to the UI was a good idea? All it's doing is exposing all the issues that continue on error has that haven't been addressed for years

frosty bridge
#

I think continuing after a service call fails with an unexpected exception is OK

#

We would have continued if the integration caught and rethrew the errors as HomeAssistantError

#

We should not do the same for other script actions though IMO

cold palm
frosty bridge
#

But only service call errors, or any error at all?

cold palm
#

well users are expecting any error at all

#

Partly why I brought up the conversation, the name of the property implies "all errors"

#

when the reality is "only errors we decide but do not really tell you what those are"

frosty bridge
#

Haha, yes yes

#

I see. So do you think we should change anything?

cold palm
#

I'd assume that continue_on_error does exactly what it says for everything except for configuration errors. Which can be easily explained to any user.

#

So I'm not sure if there's a ton of reworking required if you just allow other exceptions in the continue_on_error catch

#

Disclaimer: I haven't looked at the code, so I'm not sure if what I'm saying is feasible

frosty bridge
#

I don't think there are expected errors from anything else than service calls though

#

Which is why I suggested to modify only those

cold palm
#

I was only expecting a wrapper of sorts around the service call that just catches exceptions

frosty bridge
#

Yes, that's exactly what I had in mind. Go for it if you want 🙂

#

We should make sure the tracing is working, as in, the service call error should be visible in the trace

heady breach
cold palm
#

wrong thread?