[sensors] Handling fatal vs. transient errors

tobie has just created a new issue for https://github.com/w3c/sensors:

== Handling fatal vs. transient errors ==
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.





Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/93 using your GitHub account

Received on Friday, 18 March 2016 10:28:15 UTC