Subj : Re: Error handling
To   : netscape.public.mozilla.jseng
From : Brendan Eich <brendan@meer.net>
Date : Tue Aug 05 2003 05:31 pm

Brendan Eich wrote:

> Braden McDaniel wrote:
>
>>> I didn't have time to look further last night, but now it seems to me
>>> that we need another callback, at least, akin to JSErrorCallback but
>>> with a JSExnType result.  Or, we could jam a JSExnType member into
>>> JSErrorFormatString and copy that result-member into a new
>>> JSReport.exnType member.  Either approach requires embedding code
>>> changes; the latter avoids yet another callback.  Comments?
>>>   
>>
>>
>> The latter is a bit ugly, at least in that adding an exception type 
>> member
>> would make JSErrorFormatString seem misnamed. I'm not sure it's wise to
>> change the semantics of What that struct Is. Yet Another Callback 
>> doesn't
>> strike me as particularly onerous given the existing design.
>>
>
> Agreed.  Yet another callback coming up. 


Ugly doesn't begin to describe this, though.  The existing APIs take a 
funarg, of type JSErrorCallback, and we can't extend them -- they're 
frozen.  New error-reporting APIs that Braden and others might use could 
take two callbacks, one a JSErrorCallback (really an error message 
fetcher -- too late for better naming), the other a error to exception 
type index mapper.

But (a) the JSExnType is hidden in jsexn.c; (b) we don't want to bloat 
the API with a bunch of clones of 
JS_ReportErrorNumberAndFlagsAndExceptionTypeIndexMapper noise; (c) I'm 
not happy about putting a callback in cx or even the runtime, if it's a 
companion to the error message fetcher, which is a free parameter of the 
API, not a callback stored in cx or rt.

Braden, your thoughts are welcome.

/be

.