Handling fatal vs. transient errors

[tobie]

While some errors are clearly fatal (e.g. when the permission to use the sensor is denied, there's no point in continuing to listen to it) some might just be transient (e.g. a reading took longer than usual and triggered a timeout error) and the situation might resolve by itself without further involvement (the error becomes more of a warning in that case).

I see two ways to look at this:

1. Make a distinction Between Fatal and Transient Errors

Split up DOMExceptions somewhere along the following lines:

Fatal Errors

_Fatal errors_ would:

1. reject an eventually unresolved start promise,
2. emit an error event,
3. stop the Sensor object, and
4. change the sensor's state to "error".

These would be considered as _fatal errors_:

• NotAllowedError (The request is not allowed by the user agent or the platform in the current context.)
• SecurityError (The operation is insecure.)
• NotSupportedError (The operation is not supported.)
• AbortError (The operation was aborted.)

Transient Errors

_Transient errors_ would only:

1. emit an error event.

and would:

1. not reject an eventually opened start promise,
2. not stop the Sensor object, which would stay "active", and
3. not change the sensor's state to "error".

The following would be _transient errors_:

• TimeoutError (The operation timed out.)
• OperationError (The operation failed for an operation-specific reason.)
• NotReadableError (The I/O read operation failed.)
• UnknownError (The operation failed for an unknown transient reason (e.g. out of memory).)

2. Consider all errors as fatal, surface non critical issues though dedicated events.

The idea here is to consider transient issues as noteworthy but not exceptional unless further operation of the sensor is compromised. While it's useful to make these issues bubble up, they shouldn't interfere with the rest of the program unless the API consumer specifically takes steps to do so. These issues would be surfaced through dedicated events, for example, a frequencydrop event could be emitted by the device when it started polling at a lower rate than requested because it of switching into a battery-saving mode.

So you'd basically have _Errors_ which would:

1. reject an eventually unresolved start promise,
2. emit an error event,
3. stop the Sensor object, and
4. change the sensor's state to "error".

And _dedicated events_ which would:

1. just be emitted as specific eventa (e.g. frequencydrop).
2. not reject an eventually opened start promise,
3. not stop the Sensor object, which would stay "active", and
4. not change the sensor's state to "error".

This seems like a more sane approach, it's easier to explain and can be built in separate stages more easily. Level 1 would only handle fatal errors, and a level 2 spec could add dedicated events as needed.

[anssiko]

Sounds right. Let's ship the "consider all errors as fatal" part of option 2 in v1 and leave dedicated events to v2.

After we've gotten some implementation feedback, we're in a better position to tell what type of dedicated events might be needed, if any.