How to handle exceptions in the specification

[m-mohr]

Should errors be "optional"?

Is the specification a best-practice and implementations can change (throw an error) or should always keep the option open (may throw an error).

[m-mohr]

Candidates:

• apply_kernel
• aggregate_temporal?
• vector units
• log / ln / divide / mod
• merge_cubes? (see also merge_cubes: resample implicitly #402)
• ndvi
• save_result

[m-mohr]

We discussed this today (vote: ++++oo). The consensus was to be strict in the user-facing documentation (i.e. the JSON process specification) so that errors are clearly stated without a "uncertainty" such as "may throw". Back-ends can extend their implementations and remove the exception from the documentation. For back-end implementations we add more documentation to the back-end implementation guide (and promote/use it more).

For this issue there is no further to do as we follow our past principles.