- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 28 Aug 2012 08:22:55 +0200
- To: Eric Rescorla <ekr@rtfm.com>
- CC: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 08/27/2012 04:58 PM, Eric Rescorla wrote: > On Mon, Aug 27, 2012 at 7:52 AM, Harald Alvestrand <harald@alvestrand.no> wrote: >> On 08/27/2012 04:33 PM, Eric Rescorla wrote: >>> >>> On Sun, Aug 26, 2012 at 11:30 AM, Stefan Hakansson LK >>> <stefan.lk.hakansson@ericsson.com> wrote: >>> >>>> Perhaps we should change this; instead have more frequent telcos with >>>> fewer >>>> topic which we cover in depth. I would certainly be open for that if the >>>> WG >>>> (and my co-chair) thinks it is a good idea. And it would be natural to >>>> focus >>>> on covering the issues (in priority order) that block implementation in >>>> those meetings. >>> >>> For my money, the best use of telcos is to resolve issues which aren't >>> getting >>> resolved on the list. >>> >>> My priorities may not match anyone else's but here are the things >>> that I think are high priority (as in they are questions that are already >>> holding up implementation): >>> >>> - A complete description of error handling. I.e., which functions throw >>> exceptions, which have error callbacks. Do the functions which have >>> error callbacks ever throw exceptions? What is the state of affairs >>> after an error has occurred? Full disclosure: my position is that >>> any given API call should have exactly one error reporting mechanism. >>> >> Eric, can you point to some API that describes its error handling clearly >> enough that we can use it as a pattern? >> >> This one's been bothering me for a while, in that I see the need, but not >> how to answer it (or a volunteer to write a proposal). > > You mean a Web API? My model here is unix man pages which pretty > much describe everything that can happen and exactly what errors > are returned. > > In terms of a proposal, I think the issue here is that it's not a discrete thing > but rather a set of principles (prefer callbacks over exceptions, only one > type of error handling per function, etc.) and then a detailed application > to each operation. I'd be willing to do this, but I don't really want to do > it and then have it turn out that people hate my principles. FWIW, I think, we should refer to the DOM4 spec for error types [1]. Other newer specs seem to do so, and there is a note in that spec saying that if other error types are needed (something that is likely in our case), they can be added. Ekr, if you want help in drafting I would be able to spend some time on this. [1] http://www.w3.org/TR/domcore/#error-types-0 > > Perhaps what would make sense would be to enumerate those principles, > try one or two function points, and then see what people think? I would > be willing to do that. > > -Ekr >
Received on Tuesday, 28 August 2012 06:23:20 UTC