openlp-core team mailing list archive

[Zachary Steele <zcsteele@xxxxxxxxx>]

Raoul -

First off, thanks for the work you've done to make the UNO interface
function at all, given the state of that package.  I can empathize with
the rather unenviable position of needing to write writing code
dependent on a poorly designed resource.

However, I see a couple of flaws in your argument for not attempting to
add code to OpenLP for handling external-related errors.

First off, you make the statement "there is no GUI".  OpenLP's GUI is
based on Qt; the startup code imports the necessary Python dependencies
during the startup process.  If the Python interpreter was unable to
load those resources it wouldn't even execute the call to
create_engine() in the first place.  The db.py file I have attached
demonstrates this by displaying the Qt popup (without any secondary
errors!) during the failure condition.

Secondly, you refuse to to make any attempt to cope with "everyone
else's bad bugs".  I'm not suggesting that you go around coding patches
for every project that has any possible affect on OpenLP; what I am
endorsing is "defensive programming" - much akin to the "defensive
driving" taught in driving classes.  As you can see with my attachment,
the additional code is not at all complicated but allows OpenLP to
report a meaningful error when LibreOffice (or any potential future
replacement) fails.

You said "OpenLP development would be even slower".  There is an element
of truth to this, but how much time do you really lose by dropping my
code in to the project?  Also, as an open-source project there is not a
hard cap on the number of active participants.  I for one have no
problem contributing to the codebase but if you really *want* OpenLP to
be brittle I won't bother you with such issues in the future.

One point of consideration you may have missed is that of the end-user
perspective.  While any developer can trace the root cause of something
like this back to its (external) source,  all a user can see is "I
clicked on the program, and then it crashed".  The end-user is going to
blame OpenLP because that was the program they were trying to run, not
LibreOffice (which seems fine from an end-user perspective).  I doubt
most of the users are even /aware/ that the song database is tied to
LibreOffice.

-- 
You received this bug notification because you are a member of OpenLP
Core, which is subscribed to OpenLP.
https://bugs.launchpad.net/bugs/1223644

Title:
  OpenLP fails to start  if python-uno throws an exception

Status in OpenLP - Worship Presentation Software:
  New
Status in OpenLP 2.0 series:
  Won't Fix
Status in OpenLP trunk series:
  Won't Fix

Bug description:
  As of OpenLP 2.0.2, the startup code is unable to handle external
  errors which cause python-uno to throw exceptions.  In this particular
  instance,

  Current behavior:
  After running OpenLP with the option "-l debug", the following stack trace is logged:
   File "/usr/bin/openlp", line 44, in <module>
      main()
    File "/usr/share/openlp/openlp/core/__init__.py", line 342, in main
      sys.exit(app.run(qt_args))
    File "/usr/share/openlp/openlp/core/__init__.py", line 150, in run
      self.mainWindow = MainWindow(self)
    File "/usr/share/openlp/openlp/core/ui/mainwindow.py", line 685, in __init__
      self.pluginManager.find_plugins(plugin_path, self.pluginHelpers)
    File "/usr/share/openlp/openlp/core/lib/pluginmanager.py", line 121, in find_plugins
      plugin = p(plugin_helpers)
    File "/usr/share/openlp/openlp/plugins/custom/customplugin.py", line 54, in __init__
      self.manager = Manager(u'custom', init_schema)
    File "/usr/share/openlp/openlp/core/lib/db.py", line 229, in __init__
      self.session = init_schema(self.db_url)
    File "/usr/share/openlp/openlp/plugins/custom/lib/db.py", line 61, in init_schema
      session, metadata = init_db(url)
    File "/usr/share/openlp/openlp/core/lib/db.py", line 64, in init_db
      engine = create_engine(url, poolclass=NullPool)
    File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/__init__.py", line 321, in create_engine
      return strategy.create(*args, **kwargs)
    File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/strategies.py", line 64, in create
      dbapi = dialect_cls.dbapi(**dbapi_args)
    File "/usr/lib/python2.7/dist-packages/sqlalchemy/dialects/sqlite/pysqlite.py", line 276, in dbapi
      from pysqlite2 import dbapi2 as sqlite
    File "/usr/lib/python2.7/dist-packages/uno.py", line 334, in _uno_import
      "%s (or '%s.%s' is unknown)" % (py_import_exc, name, x)
  AttributeError: 'exceptions.ImportError' object has no attribute 'with_traceback'

  
  Expected behavior:
  OpenLP should provide the user with an error dialog before crashing with a message such as "OpenLP is unable to connect to the LibreOffice database".
  If it is reasonable, add workaround code to allow OpenLP to continue without using the plugin which triggered the external exception.

  Environment notes:
  OpenLP 2.0.2
  Ubuntu 12.04
  Libre Office 4.1.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/openlp/+bug/1223644/+subscriptions