Skip to content
Browse files

Add note on GeoAlgorithmExecutionException

  • Loading branch information
nyalldawson committed Jul 15, 2017
1 parent 4e2605b commit e039a0643fcb549a781bf7a7c22aac59b7ecd611
Showing with 3 additions and 1 deletion.
  1. +3 −1 doc/porting_processing.dox
@@ -61,14 +61,16 @@ feedback object. E.g.
feedback.pushInfo('Feature {} was missing geometry, skipping'.format(
feedback.reportError('Input layer CRS is not valid, cannot reproject')

- Use geoprocessingexception only for FATAL errors which force a model to terminate. Algorithms should handle common cases
- Use exceptions only for FATAL errors which force a model to terminate. Algorithms should handle common cases
such as having no features in an input layer without throwing exceptions (instead, an empty layer should be output). This
allows more flexibility for users creating models. They may have created models which "route" features to different algorithms
based on some criteria, and it can be a valid case that no features satisfy this criteria. If your algorithm throws an
exception upon encountering an empty layer, it prevents it being used in these flexible models. Instead, use the feedback
object to pushInfo or reportError so that the lack of features is brought to user's attention (and logged) without breaking
the model execution.

- But if you MUST throw exceptions, use QgsProcessingException instead of the removed GeoAlgorithmExecutionException.

- Outputs are good! Declare as many outputs as useful from your algorithm. E.g. most algorithms should have at least a
FEATURE_COUNT number output which records the number of features processed by the algorithm. Other algorithms might want
to create numeric outputs for values like INTERSECTING_FEATURE_COUNT, NON_INTERSECTING_FEATURE_COUNT, etc. The more

0 comments on commit e039a06

Please sign in to comment.
You can’t perform that action at this time.