Skip to content

Commit

Permalink
Add note on GeoAlgorithmExecutionException
Browse files Browse the repository at this point in the history
  • Loading branch information
nyalldawson committed May 11, 2018
1 parent 4e2605b commit e039a06
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion doc/porting_processing.dox
Original file line number Diff line number Diff line change
Expand Up @@ -61,14 +61,16 @@ feedback object. E.g.
feedback.pushInfo('Feature {} was missing geometry, skipping'.format(f.id())
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
Expand Down

0 comments on commit e039a06

Please sign in to comment.