8. How Errors are Handled

A vital principle to all modular systems is Do it right or signal an error. It is illegal (a bug) to accept a function/method call and then do nothing, or worse, do the wrong thing. Likewise, it is a bug to return incorrect data when reading a variable/property, or corrupt a value being written to a property. This may seem obvious but it can be subtle.

In all modern software, errors are declared by a signaling mechanism. If the method or property cannot, for any reason, do the right thing, it must signal an error. The caller experiences a "run time error", also called an exception, and is responsible for reacting in some sort or rational way. An app that fails to handle a run-time error will crash (unhandled exception, "xxx has stopped working", etc.). Silent failures are a serious violation of this principle. Let's take a couple of examples:

Suppose a roll-off roof controller is tied into safety position sensors which electrically prevent the roof from moving unless the scope is parked (a common configuration). Now let's say the scope gets bumped or fails to complete parking somehow. Then the app calls OpenShutter() and nothing happens. The roof controller activates the motor relay, but the sensors have cut off the power for safety. This is a bug. The roof controller must know that it cannot open the roof in this case and signal an error "cannot open, safety sensors are tripped". A silent failure (call to OpenShutter() without an error yet no roof motion) is a bug, plain and simple.

Another subtle example is a roof controller which, after being called to OpenShutter(), takes "a few seconds" to move the roof enough to clear the roof-closed microswitch. During these few seconds, the ShutterStatus property might report ShutterClosed. This is a lie -- the shutter has been successfully told to open (no raised error from OpenShutter) so it must be in the state of opening (or maybe it's already open). Just because it takes a second or two to "get going" doesn't matter. Anything but opening or open is an unexpected condition. An app, seeing a successful call to open, then looking immediately thereafter and seeing closed, is well within its rights to stop everything and declare a problem.

Modular system stability and reliability is critically dependent on all components adhering to this rule.

When something does go wrong, it's critical that there is a reasonable way to diagnose a problem. ASCOM's universal interfaces help isolate the problem as you can see in 9. Problem Solving.