Preventing runtime errors

I have built most of my automations with appdaemon apps, the problem I have is not so much with appdaemon but with python itself.

I am used to working with a compiled language that has static typing, python is (afaik) none of those.
So when doing rewrites of my automations or adding new functionality i sometimes end up braking my system in a way that I don’t notice it until that particular pice of code runs (usually right before i go to bed for some reason). Errors that to 99% would be catched by a compiler at compile time.

I am not a python developer by trade, so is there something i am missing?
How do other people handle this?

On the top of my head I can think of a few ways:

  1. Manually run through all thinkable scenarios when making larger changes.
  2. Create and run test suites for the automations.
  3. Static code analysis.
  4. ?

/ David

I guess it comes down to experience and test coverage - instead of testing the condition when you go to bed, use the developer tools to force the state changes so you can test it there and then - I do that for a lot of my automations.

my system is quite simple.

  1. dont make big changes to running, important code all at once, but save in between.
  2. after every save check your error log.

i have the "normal"log always on screen, so when i save i see immediatly when the app starts up as it should.
so at least i know that i have no errors that prevent the code from running.

off course i sometimes use vars that are not valid at that point, but most of the time only in new code.
and when a new piece of code breaks, ah well no big deal its not an automation i already rely on.

if it is possible i use another trigger to check if i got it correct (if an automation only runs once a day, or on times i dont want to check for instance)
in stead of a listen state from a motion sensor far away, i use one that is near, i change the time, etc.

1 Like

by the way i forgot to mention the option to use time travel.
i never use it, but it is an option to make sure you have no error when you go to bed :wink:

1 Like

Thanks for your replies.

I do have windows open with error log and the normal log, and during the actual development I think the workflow is as good as it gets with this kind of setup.
(It’s much much better than domoticz that i used to run)

The problem is with the errors that occur in the special cases and when certain conditions are met.
Sure, I could probably try to force more state changes manually when testing, I do that for the most common cases now but not for everything.

I guess I am spoiled (or whatever you would call it) being used to a compiled language with stricter type checking, and most of the errors I find in my python appdaemon app development (when I don’t want to find them) are simple spelling errors/syntax errors and stuff like that, it just seems unnecessary waste of time not being able to do some sort of compile/static code analysis to catch those before runtime.

I would suggest you take a look at a full IDE like PyCharm - among many other things, it will highlight things like misspelled variable names etc. while you are editing, and would go a long way toward bridging the gap between compiled and interpreted languages.

2 Likes

Just wanted to provide an update.
I have been using emacs for a long time and will probably stick with that for the time being.
Running flycheck with pylint in emacs made the process a whole lot better, it’s remarkably good at picking up on errors.