Non recoverable error conditions and reporting implementation status

Moved from issue #8 (Bugzilla 16059) as discussed meeting 30/01/2017. Deemed better as a new separate issue. To be re-worded and remove comment 3 list item 3. Re-edit to mention watch dog or cross checking verification systems to allow for reporting of status. This issue is related issue #8.

Comment 3 illya@codeplay.com 2016-11-15 03:49:39 PST

Discuss: Ideally there should not be any non-recoverable error conditions. As a guideline the implementers should consider however if there are non-recoverable states then the client (developers using the SC API) should be made aware off the following:

1. all known non-recoverable states
2. an error code if any for each non-recoverable state
3. how the non-recoverable state can be entered
4. how to recover from the recoverable state to return to normal expected behaviour state
5. if the non-recoverable state has been entered does it switch to a safety mode of operation i.e. it is continuing to work but at reduced functionality. State the behaviour when in this mode.

This would allow the client to develop tests for those states and where applicable verify their recover processes do work.

Comment 4 illya@codeplay.com 2016-11-22 00:36:27 PST

From discussion it was not clear the intention of comment 3.
The implementer should provide as much documentation as possible on the reasons a for undefined state behaviour represented by the returned error code. This is very much implementation specific and so nothing more can be added in the guidelines apart for a strong recommendation. If the user has done his due diligence anyway they should be asking such questions anyway especially is the implementation is a black box - what are the side affects?