[Qgis-developer] segfault python: no catch for QgsException?

[Martin Dobias]

On Tue, Nov 24, 2009 at 10:50 PM, Richard Duivenvoorde
<rdmailings at duif.net> wrote:
> He Martin,
>
> Thanks for your answers,

Hi and sorry for taking it so long to get back to you...


> Martin Dobias wrote:
>>
>> what QGIS version is that? Here on svn trunk I get just a message box
>> with the error message and no crash - supposedly thanks to a last
>> resort try...catch block in QgsApplication.
>
> svn trunk ...
> doing it with r12220 or 12214, not sure which tree I used ...
> Both as a plugin and in the python console Qgis just crashes when I do
>
> from PyQt4.QtCore import *
> from PyQt4.QtGui import *
> try:
> QgsProject.instance().read(QFileInfo('/home/richard/temp/test.dbf'))
> except:
>        print 'FOUT'  # dutch for 'ERROR' :-)
>
> after I read a valid project into qgis first...

Hmm... on my comp it still shows the error message box "unable to open
..." and crashes with a segfault in python libs later when executing
any other python command - I guess due unexpected change of flow
because of the exception. On another computer it just aborts
immediately due the exception.


>> The exceptions are not recognized in Python because they're not
>> wrapped in SIP. Barry had a similar problem few months ago:
>> http://lists.osgeo.org/pipermail/qgis-developer/2009-January/005887.html
>>
>> I still think we should remove usage of exceptions from QGIS codebase
>> - either to make the API simpler and also more Qt-like. But someone
>> would have to do it :-)
>
> Removing exceptions? ... How would you handle stuff like above then (or do I
> sound very old-fashioned now ;-) ). Seriously, does Qt have an alternative
> for this?

A common pattern for handling errors without exceptions is like this:

if ( ! x.open() )
{
  printf("error: %d\n", x.error();
}

instead of:

try
{
  x.open();
}
catch ( exception e )
{
  printf("error: %d\n", e.error());
}

This is how Qt does it too - check e.g. QFile docs.

Looking at the QgsProject class, the only methods that throw
exceptions are read() and write(). Both currently either return true
on success or end up throwing an exception. So we could remove the
usage of exceptions without a lot of fuss just by returning false on
error and adding a method to return error type (or error message).
This would be actually a tiny change in API semantics, but I think
it's worth it (considering that python plugins have trouble with
dealing the exceptions).

> If there is a good alternative, we could make it a task for people who want
> to start cpp (like me and Werner...) maybe?

Well... I can try, it might be a good excercise - depends on how much
c++ knowledge you've acquired already :-) Anyway I think I'll might
find some time during 1.4 bugfixing period to do the changes... if
there are no objections against the proposal from other devs.


Martin