Recommended plugin error handling

Hi,

I've wondered a bit on how to do good error/exception handling in plugins, is there some particular way that can be considered recommended?

An example

Code: Select all

try:
    # do some calculation or other stuff
    pass
except ValueError:
    # example of some "expected" error based on user input or other invalid input etc.
    self.logger.error(u'There is something wrong in some input')
except:
    # Unexpected error, should normally not happen
    self.logger.error(u'An unexpected error happened. This is a more user-friendly description')
    raise # re-raise the exception to get stack trace


Comments to this?


Another question, say the plugin discovers a critical error (in configuration, reading external files etc.) that makes it pointless to leave the plugin running. Is there a way to quit the plugin from within the plugin? I think it is mentioned in the documentation that raising an exception in __init__ will stop the plugin, is that a recommended way to handle such errors?
And say that a critical error is discovered later on, while the plugin is running, how should that best be handled?

Thanks!

[jay (support)]

There isn't really a good blanket way to handle fatal exceptions because there's a wide range of what "fatal" can mean. A fatal error in a specific device, for instance, may mean that device should be disabled but not the entire plugin. A fatal network connection error may mean that the plugin has to go into a retry mode until the communication is reestablished. So, unless your plugin just can't possibly do anything at all, you probably want the plugin to continue to try to operate as best it can. If it's a config error, then you can just throw periodic errors into the event log telling the user that the config is invalid and that they need to fix it (and do nothing else).

Be careful when you raise exceptions out of the code that you directly control - it may not do what you expect (and it's not guaranteed to do what it's doing now in future versions). The best bet is to handle any exceptions you see. You can write your own stack traces to your log file (or the Event Log if you want) using the traceback module.

[matt (support)]

Another question, say the plugin discovers a critical error (in configuration, reading external files etc.) that makes it pointless to leave the plugin running. Is there a way to quit the plugin from within the plugin? I think it is mentioned in the documentation that raising an exception in __init__ will stop the plugin, is that a recommended way to handle such errors?

Raising from __init__ is a good way to handle a fatal plugin startup problem. Doing so will put the plugin in suspended state where it is no longer running but isn't technically "disabled" in the sense that if the Indigo Server is restarted the plugin will be relaunched.

As Jay mentioned, other Indigo Server callbacks should try to handle the exceptions themselves.

And say that a critical error is discovered later on, while the plugin is running, how should that best be handled?

You can call self.stopPlugin() to tell the Indigo Server to shutdown a plugin, which puts it in the same suspended-but-enabled state described above.

We rarely use that call though for our plugins. In general if something stops working (because of a network connectivity issue, hardware error, etc.) our plugins will continue to retry every several seconds to see if the problem has been corrected so that no user interaction is necessary on the Indigo side once the problem is cleared up.

Thank you both for good clarifications!

I agree in most cases I would leave the plugin running. However in one case I have a static csv file included in the plugin bundle, and is quite crucial for operation. If for some reason the plugin can't read the file I don't expect that to be resolved and thought it would be a good idea to then stop the plugin. If other plugins call actions of this plugin and check by .isRunning() they would be informed that the plugin is not available for executing actions.

Be careful when you raise exceptions out of the code that you directly control

Sorry, I didn't quite understand this. Do you mean that I shouldn't re-raise exceptions as I did in the example? Only python experience is from Indigo, more used to PHP, so the exception handling in python is a bit difficult to grasp

[jay (support)]

Sorry, I didn't quite understand this. Do you mean that I shouldn't re-raise exceptions as I did in the example? Only python experience is from Indigo, more used to PHP, so the exception handling in python is a bit difficult to grasp

In general, that's correct, you don't want to raise an exception out of your code. Your snippit doesn't show enough context for me to know if it's appropriate or not. But, for instance, if you catch an exception in the deviceStartComm method, you shouldn't raise an exception out of that but rather just handle it yourself. Another example is raising an exception out of the runConcurrentThread method - that will cause the plugin to restart which is likely not what you want it to do.

You can raise exceptions in your code if that exception will be caught by some other part of your code. For instance, if you have a custom class that you built to do something, then you can certainly raise exceptions out of it - as long as those exceptions are caught by some other part of your code.

[matt (support)]

I agree in most cases I would leave the plugin running. However in one case I have a static csv file included in the plugin bundle, and is quite crucial for operation. If for some reason the plugin can't read the file I don't expect that to be resolved...

Yes, that is very similar to how plugins internally handle their XML files. If they aren't parsable at init time then an exception is thrown and the plugin shuts down. No way that is going to fix itself.