avesus/errors-handling.md

## errors-handling.md

      
    Raw
  

              errors-handling.md
            
          
Use http://sweetjs.org/ to implement condition checkers.
Монада maybe на Promise'ах (строчка return default;):

newAsyncFunc().then(function(success) {
    return anotherAsync();
  }, function(error) {
    return default;
  }).then(function(success) {
    return yetAnotherAsync();
  }, function(error) {
    return default2;
  });


Bugs:
all kinds of invalid implementation.
Detected as external contract violation ONLY.
All kinds of internal assertion checks ONLY helps to localize a bug.
Detection technics:


overall integration testing to check contracts


runtime checks (???) - localization technique only, we couldn't dynamically predict which result should be
(for a RANDOM client request, only CLIENT knows which result is correct - but ever this is not true.
We could respond with correctly-looked result, but it could be erroneous - and nobody will know
while some output of a subsequent system (or a user) will got outcome).
When such bug will be localized and fixed, there will be a regression check (runtime check or in tests only?),
could the bug be detected by means of post-assertions?
Runtime check could be implemented in system code after it does its job - right before return result to client.
Pre-processing checks are for client contract check (see Valid input below) and invariants
(system's internal state and depended systems conditions, i.e., network, HDD/RAM size, CPU load, etc.)
System could check available RAM and CPU before function execution if request should be processed quickly.
Other ways to guarantee invariants - reserve RAM/CPU/HDD/Network Bandwidth and another resources before
processing.


Invalid input:
Intentional or unintentional contract violation from client side.
Should be detected by external layer of system's input.
Graceful result code handling only - exceptions shouldn't be passed between system and client,
because it will be inverted control of client by system.
Result code handling should be a part of system's contract - client's failure to specify a valid input
should not move system to its contract invalidation.


System errors:
Contract violations by external executive actors which are NOT PART of the system.

MUST be handled gracefully
MUST be retryable
MUST be passed to client level to control

Contract violations by internal parts of the system (any part, in principle):
System could decide to retry with another (not buggy now) part at runtime (but consider to log bug!).
Such retry is considered very rare, so...
If retry is not possible, the part's violation is violation of the whole's contract - the system contains bugs,
and have to report it loudly (fail fast?).
In case of such fails, system should switch to fail-safe mode with minimum basic functionality.
In principle, production-grade system, when it provided NEW functionality to a client, couldn't
switch back to previous version - but client could choose to switch back.
If system was worked with user's data (wich HAVE TO be migrated backwards to previous version),
it should save user's data as much as possible (but new functionality will be lost!).
Described failover switch to previous "stable" version could be used at runtime for a user who triggered
some buggy parts. But every another user could too. So, beta-testing could come to continuation of using
buggy parts - if it is possible.
Downgrade is always a user-choosen step. (In most systems it ever not supported at all).
So, if not downgrade, then what? Just store user's data. In new version. Show excuses.
Contract violations by executive actors which are called by system to do its job. Must be handled gracefully in all places.
ONE IMPORTANT NOTE ABOUT CONTAINERS AND OWNERSHIP:
If executive actors are available to client (semantically known and accessible), system errors handling COULD be raised
to client's level by specifying system error condition in system's contract.
Otherwise, errors in internal parts of the system which COULD be handled, MUST be handled.
BUT: errors are: a) detectable contract violations and b) bugs.