Re: Error handling description (Re: First agenda proposal webrtc telco)

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