[web-bluetooth] getPrimaryService (and similar) should throw if UUID is not found

scheib has just created a new issue for 
https://github.com/WebBluetoothCG/web-bluetooth:

== getPrimaryService (and similar) should throw if UUID is not found 
==
After requestDevice succeeds for my set of services, an application 
believes it has access to a device that supports known services. Those
 services have known characteristics. Calling getPrimaryService(uuid1)
 and getCharacteristics(uuid2) should only have a promise fulfilled if
 services and characteristics existed and were obtained as expected. 
Applications shouldn't need to check for errors int he fulfillment of 
that promise:

```
navigator.bluetooth.requestDevicerequestDevice({
  filters: [ {services: [uuid1]} ]
}).then(function(device) {
  return device.connectGATT();
}).then(function(gattServer) {
  return gattServer.getPrimaryService(uuid1);
}).then(function(service) {
  return service.getCharacteristic(uuid2);
}).then(function(characteristics) {
  // Code here trusts that my requests have been fulfilled correctly.
  // If my uuids were correct, I know exactly the service, and that it
  // has certain number of characteristics with uuid2.
  // If for some reason they are not found, it is exceptional and
  // should have rejected a previous promise.
  characteristics[5]; // should exist and be valid without checking.
}).catch(... oh noes, normal exception handling ...);
```

- getCharacteristic requires a UUID, and it makes sense to reject if 
that uuid isn't found.
- getCharacteristics with a provided UUID should reject if not found 
for similar reasons.
- getCharacteristics without a provided UUID requires additional 
thought. I could go either way at the moment: I suppose if specific 
UUID isn't provided then the application doesn't have an expectation 
of what it will receive back, and an empty set may be valid. 
Consistency with "NotFound" == reject promise for the previous forms 
is reasonable as well.

See https://github.com/WebBluetoothCG/web-bluetooth/issues/124

Received on Thursday, 28 May 2015 23:59:36 UTC