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
