A number of updates #34
Conversation
ClaesNilsson
commented
Jul 4, 2013
ClaesNilsson
commented
- Error handling: Error handling to be revised #18
- Permission: Introduce a permission in section 4, based on Runtime and Security spec #21
- Local address/port attributes: Expensive to synchronously set TCPSocket.localAddress when using default local address #24
- Naming of join/leave multicast group methods: Join/leave group #27
- Erroneous send steps: Step 2 in send steps is wrong #30
- Added ref to Github repository in header
* Error handling: sysapps#18 * Permission: sysapps#21 * Local address/port attributes: sysapps#24 * Naming of join/leave multicast group methods: sysapps#27 * Erroneous send steps: sysapps#30 * Added ref to Github repository in header
|
review started ... 7 minutes late! :) |
|
Thanks!!! |
| buffered but the buffer is full or because there is an error in the | ||
| underlying protocol, the user agent MUST set an internal | ||
| "IgnoreAllSendCalls" flag and <a>queue a task</a> that executes | ||
| the following substeps and then abort the following steps: |
There was a problem hiding this comment.
What is different in this API from Web Sockets that requires asynchronous error handling? We can handle this as a separate bug. I'm just wondering.
|
I think it's ok to merge, but have some strong reservations about the error handling model that has been defined. |
|
The background to theses updates on error handling is a mail dialogue between me and Jonas: So, the basic problem with error handling that Jonas addresses is that with the standard DOMError interface the granularity of machine readable error names are too limited. An example is when the attempt to create a TCP socket fails. The reason can for example be "no network contact"," peer does not respond" and "local address/port pair is already in use". The available DOM error names does not make it possible to separate these error reasons and the only sensible error name for all these situations is "NetworkError". In the previous version of the specification I tried to solve this problem by distinguishing between these error reasons with the DOMError message attribute. However, the message attribute contains an implementation dependent message to be displayed to the user. Using this attribute does not make machine readable handling of errors possible, i.e. the application can not be coded to handle these dirrent error reasons in different manners. The http://darobin.github.io/api-design-cookbook/ does not give much guidence here. So after discussion with Jonas I took the approach of subclassing DOMError and added the "type" attribute that provides a more detailed error definition than the "name" attribute. This problem with error handling is probably applicable for more W3C specifications and it would be good if the authors of the DOM-specification stated a recommended approach on how to define a more granular error handling. |
|
@ClaesNilsson thanks for the background - I understand the issue and rationale (though I'm still feeling uneasy about it - but that's probably a bit of my ignorance on the subject). I'll read those threads. Please feel free to merge and I can follow up in bugs. |
|
Merged now. Thanks for your review Marcos! |
