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
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
[email protected] http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
