- From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
 - Date: Fri, 29 May 2015 00:36:22 +0000
 - To: public-web-bluetooth-log@w3.org
 
(You probably mean to call `service.getCharacteristics(uuid2)`, since 
[`getCharacteristic()`](https://webbluetoothcg.github.io/web-bluetooth/#dom-bluetoothgattservice-getcharacteristic)
 returns at most 1 object, not 6.)
If the developer calls `requestDevice(filter: [{services:[uuid1]}, 
{services:[uuid3]}])` then they need to call 
`getPrimaryService(uuid1)` to figure out which filter their device 
matched. Getting `null` back from that call isn't exceptional.
There are also cases, like in the 
[`heart_rate`](https://developer.bluetooth.org/gatt/services/Pages/ServiceViewer.aspx?u=org.bluetooth.service.heart_rate.xml)
 service, where certain characteristics are optional in the Service 
definition. It's not exceptional to request the `body_sensor_location`
 characteristic and get nothing back.
There are definitely other cases where the developer expects to always
 get a value back (`heart_rate_measurement`, for example), and the 
current design would produce a `TypeError: Cannot read property 
'getCharacteristic' of null` if they didn't explicitly check the 
result.
We also have the chance that the device has moved out of range, in all
 of these cases. I wouldn't want developers to confuse that with an 
optional characteristic being absent.
I don't feel particularly strongly about this choice, but I suspect we
 should wait for developer feedback to finalize it.
-- 
GitHub Notif of comment by jyasskin
See 
https://github.com/WebBluetoothCG/web-bluetooth/issues/124#issuecomment-106641262
Received on Friday, 29 May 2015 00:36:24 UTC