[Qgis-developer] problem with feature request and updateFeature

Marco Hugentobler marco.hugentobler at sourcepole.ch
Mon Mar 25 01:25:14 PDT 2013


Hi Matthias

>We've got QgsException (although admittedly not used much) and anyone
>coding python plugins will be used to using exceptions. Is the usage of
>QgsException discouraged?


We should try to avoid exceptions wherever we can (see S. Meyers: 'More 
Effective C++', item 15, 
http://dl.irpdf.com/ebooks/Part15/www.irpdf.com%285702%29.pdf )

Regards,
Marco

On 25.03.2013 08:44, Matthias Kuhn wrote:
> Hi,
>
> On Sam 23 Mär 2013 19:19:59 CET, Jürgen E. Fischer wrote:
>>> What do you think about introducing exceptions being thrown in such cases?
>> No much.  We currently don't use exceptions at all (ok, at some internal
>> places, but not in the API).   Qt doesn't use exceptions either.   I don't
>> think it's worth to introduce exceptions just to workaround bugs.
> We've got QgsException (although admittedly not used much) and anyone
> coding python plugins will be used to using exceptions. Is the usage of
> QgsException discouraged?
>
> I agree, that it should not be used to work around bugs. Rather to
> discover them.
>
> I'm not sure, if all dataProviders will be ready to support multiple
> connections for 2.0 and in case one needs to be closed before reaching
> the end, giving appropriate information to the developer would be nice
> (can also be a return value or whatsoever). It would be nice to hear
> Martin's ideas about this as well.
>
>>> It would be easier to become aware and also to react to such problems.
>>> There can also be conditions, when the underlying data is edited while
>>> being iterated. I remember Java had something called fail-safe and
>>> fail-fast iterators, which might be worth revising for this case.
>> Can that work without revisiting the feature in the database?
> I think so. For e.g. Postgres we probably don't need to care. Iterators
> coming from the database should be fail-safe anyway.
> For other data sources, which do not provide safe iterators, handling
> changes that come from within QGIS are traceable, while for changes
> from outside appropriate signaling from the dataProvider would need to
> be guaranteed (if not yet implemented). But I may have missed something
> here and I think you know the dataProvider internals better than I do
> to estimate the current state of change-tracking possibilities, so
> please take this with a pinch of salt.
>
> Matthias
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee



More information about the Qgis-developer mailing list