Faulty plugins render Kupfer unusable

[David Schneider]

Kupfer does not handle plugin failure well at all.
When a plugin internally fails at some aspect of the defined plugin interface, Kupfer punts completely out of whatever it was doing.
This is most noticeable when first going to type in an action into Kupfer: if one of the plugins throws an exception in, say, get_items, Kupfer will just sit there. On the terminal it provides a python exception dump, but in the GUI it will simply "not respond" to the keypress.

This is bad for a few reasons:
1. A plugin should not be able to stop Kupfer from functioning. Kupfer should catch the error earlier and either unload the plugin (I know this is not implemented yet) or at least skip/ignore/remove the plugin's data.
2. If not that, an error that is stopping the proper function of kupfer should give visual feedback. Maybe display an 'error' meta-object, or display some text in the window, or pop up a dialog (preferably not the last one). Some sort feedback is required, since Kupfer still responds to keybindings--having it work in one way but not react at all in another can be baffling to a user.
3. The faulty plugin should be flagged in some way. Maybe put a tick or (!) sign next to it in the preferences screen; some way to tell the user that the plugin is failing. Make all traces accessible from that interface. Users should not have to run Kupfer in a terminal to know that the database a plugin is trying to read from is corrupt, nor should they be unable to access the trace of a transient error (say, they had the error once and had no idea how to reproduce when they run kupfer again in the terminal).

Here's an example traceback that I am having that is stopping me from using the program:
Traceback (most recent call last):
  File "/usr/share/kupfer/kupfer/core/data.py", line 299, in search
    decorator=decorator)
  File "/usr/share/kupfer/kupfer/core/data.py", line 104, in search
    items = item_check(src.get_leaves())
  File "/usr/share/kupfer/kupfer/obj/base.py", line 395, in get_leaves
    return sort_func(self.get_items())
  File "/usr/share/kupfer/kupfer/obj/sources.py", line 158, in get_items
    it = S.get_leaves()
  File "/usr/share/kupfer/kupfer/obj/grouping.py", line 76, in get_leaves
    leaves = Source.get_leaves(src, force_update)
  File "/usr/share/kupfer/kupfer/obj/base.py", line 403, in get_leaves
    datatools.SavedIterable(sort_func(self.get_items()))
  File "/usr/share/kupfer/kupfer/utils.py", line 67, in locale_sort
    seq = seq if isinstance(seq, list) else list(seq)
  File "/usr/share/kupfer/kupfer/plugin/clawsmail.py", line 137, in get_items
    for addrbook_file in self._load_address_books():
  File "/usr/share/kupfer/kupfer/plugin/clawsmail.py", line 176, in _load_address_books
    dtree = minidom.parse(self._claws_addrbook_index)
  File "/usr/lib/python2.6/xml/dom/minidom.py", line 1918, in parse
    return expatbuilder.parse(file)
  File "/usr/lib/python2.6/xml/dom/expatbuilder.py", line 924, in parse
    result = builder.parseFile(fp)
  File "/usr/lib/python2.6/xml/dom/expatbuilder.py", line 207, in parseFile
    parser.Parse(buffer, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 12, column 151

Upon attempting to type in the kupfer window that trace is dumped to the terminal, and my keypresses are not acknowledged at all in the kupfer window.

I had a similar issue when a custom plugin I made hit a parse error in one of its data files as well, to the same effect of having a nonresponsive Kupfer.

[David Schneider (dnschneid)]

Side note: other than the claws plugin not catching the error, there is nothing wrong with the processing of the address book index file; rather, the latest version of claws-mail can produce invalid XML: http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2208

[X (u78qir8a9-deactivatedaccount)]

It's correct. Kupfer only uses generic exception guards when initializing and during the first uncached load of plugins.

The coverage needs to be expanded to anytime we fetch objects from plugins. This is something that we have to build out step by step, there is no real clean model in Kupfer for this (at the moment). I think that sources call for a redesign anyway (no more instant rescan), and after some redesign of how source caching and reload works, it should be much easier to implement this cleanly.

[David Schneider (dnschneid)]

Would it be possible to at least put some sort of stopgap measure in for the next version--one that provides some visual feedback if there is an exception when typing into the kupfer window?
The current reaction (do nothing), is confusing as kupfer also tends to pause slightly at the first keypress to process its data.
The part that currently catches the exception can spit something out onto the kupfer window...something, anything...

[X (u78qir8a9-deactivatedaccount)]

I took a quick look. It's not so easy to add even a simple improvement at the moment. There is no kupfer code that catches the exception, so there is no such place to "plug in to" now.

Karol has fixed this "crasher" so a fix for that particular issue will appear in kupfer's git repo soon.

[Kevin Brubeck Unhammer (unhammer)]

also this should be in big letters in the manual: "If kupfer doesn't respond to keypresses, try disabling some plugins"