EventGhost

I'd like to see a more consistent error handling within the actions/plugins.

These are several behaviours I encountered.

• Message in Log: Lirc Server
• Error Message in Log: HID, Winamp
• Error Message with Stacktrace: USB-UIRT
• Event: ZoomPlayer.ConnectionLost
• No Message on some common "errors": USB-UIRT removed

And then there are different handlings. E.g. some program control plugins print a message, when the program is not running. Others don't.
Since you encouraged the developers to review their Configure dialog this maybe a good time to make this a more uniformly.

Personally I like the event like in the ZP plugin. Maybe a kind of special error event?!

Well, most errors are simply not expected and therefore generate a traceback. Other errors are catched, but they will disable the plugin as the plugin has no way to resume its execution from this point. The ZoomPlayer.ConnectionLost is really one of the seldom moments a plugin or action knows that something meaningful has happened before it tries to execute something.

It would be possible to generate a event like "Plugin.Error" every time an error or traceback happens, but I don't know if this is really useful for something.

I had the expected errors in mind. Like the application to control is not running, a device is missing at start up or unplugged while in and so on.
An error event triggered by an explicit call by the plugin developer would help the user to react to such error.
A totally unexpected error due to a bug should continue to print the stack trace in order to get fixed in the next version.
It would look more professional if all plugin react the same way to the same kind of error (program not running, device not found and so on). You can add this to the note to developers.

I'm open to this, but someone has to write the specifications. How about creating a wiki page for this with some suggestions you have in mind about how the most common errors should look like?

What possibilities are there currently?

• Print: Message to Log window
• Raise Error/Exception: ?
• PrintError: Message
• triggering an event (there is only the name to signal an error?)

Mostly there are two:
1. Using self.PrintError(...) to give only an error message to the log.
2. Raising self.Exception(...) to give an error message to the log and setting the plugin into error state simultaneous.

For the second case we could automatically generate a generic "Plugin.Exception" event, where "Plugin" will be the prefix of the plugin of course.

Additional data could be supplied with the event as payload.

It would also be possible to create a group of predefined exceptions, like:
* self.Exceptions.DeviceNotFound() triggering Plugin.Error.DeviceNotFound
* self.Exceptions.ProgramNotRunning() triggering Plugin.Error.ProgramNotRunning but doesn't set the plugin into error state.
* self.Exceptions.DeviceRemoved() triggering Plugin.Error.DeviceRemoved
and so on, as such predefined errors could be better translated for all plugins simultaneous.

The predefined exceptions sound like a good idea.
But the errorstate has to be configurable since the HID support hotplugging. Not sure if there are other that do that.

And I have one question to the error state with the USB UIRT and possibly other plugins.
When the USB UIRT is not connected the plugin goes into error state.
If I pugin in the device and try to restart the plugin it is still not activated.
If i disable and enable it is still not activated (Im pretty sure it worked before)
However if i enter the Configure Dialog and change one option the plugin recovers.

Yes, the resetting of the error state isn't very consistent. I started to fix this.
Forthcoming versions should reset the error state and re-raising the error if necessary on:
* Execute
* Disable/Enable
* Opening the config panel and pressing "Ok" or "Apply"

I also started to implement a generic "Exceptions" class for predefined exceptions. So I guess the general goal should be to raise an exception if something goes wrong instead of using self.PrintError. These exceptions will set a plugin into error state, if called from a plugin. If called from an ActionClass they simply interrupt the action.

So there is a difference if you call from an action:
raise self.Exceptions.DriverNotFound #this will only interrupt the action
raise self.plugin.Exceptions.DriverNotFound #this will also set the plugin into error state

What remains is to find a way how plugins can restart themselves, if a device gets connected for example.

But in the meantime it will also be possible to use the generic error messages with self.PrintError if you simply do self.PrintError(self.Exceptions.DeviceNotFound), as Exceptions have a __str__ member and thus can return their string representation.

New version is up. Some things needed some complicated changes in the error handling code, so I hope I haven't introduced to much new bugs. Next step would be to review all plugins to use the new self.Exceptions.XXX.

I will look into it next week.
Do you have changed any plugins already to have an example?
I can adapt my plugins and add a chapter to the wiki.

I've changed the USB-UIRT, Streamzap and Winamp plugin just to test the new exceptions.

ok
the plugin name in the config tree seems to stay red after the plugin has recovered.

Which plugin have you tested?

USB-UIRT
close EG
unplug device
start -> device not found message/red text
plug in device
execute on selected USB-UIRT plugin in the autostart folder.
The plugin is sending IR but the text stays red.

The "Device not found!" does not say which device. What you think about triggering an event like "USB_UIRT.DeviceNotFound" automatically?

I will look into this the next days. I'm a bit busy these days, as I have received my new Barco Graphics 808s. A plugin for Barco CRTs it is already working.