Subj : Re: Error handling To : netscape.public.mozilla.jseng From : Braden McDaniel Date : Wed Aug 06 2003 12:24 am On Tue, 05 Aug 2003 16:31:35 -0700, Brendan Eich wrote: > 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. Well, frozen or not, JS_ReportErrorNumber is broken for its intended purpose: the pattern of usage employed in js.c is not valid. Perhaps its signature could be changed to void JS_ReportErrorNumber(JSContext *cx, JSErrorCallback errorCallback, void * userRef, JSErrNum errorNumber, ...); If that change is acceptably subtle, it would at least point to the correct usage of this function. And it would be *nice* if js_GetErrorMessage could be changed to JS_GetErrorMessage, since, AFAICT, it is the only thing that should ever be used for JS_ReportErrorNumber's second argument. > 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. The error-to-exception type mapper callback argument should have been there to begin with, I think. JS_ReportErrorNumber[UC] ought to be deprecated; so, I suspect, should JS_ReportErrorFlagsAndNumber[UC]. I don't know that clutter is avoidable. -- Braden McDaniel e-mail: Jabber: .