Subj : Re: Error handling To : netscape.public.mozilla.jseng From : "Braden McDaniel" Date : Tue Aug 05 2003 05:06 pm "Brendan Eich" wrote in message news:3F2FE832.3010601@meer.net... > Braden McDaniel wrote: > > >But (for JS_HAS_ERROR_EXCEPTIONS) doesn't it get called > >regardless of whether the error messages are being pulled from my js.msg > >or SpiderMonkey's? It looks to me like: > > > > * The mapping from entries in my js.msg to JSExnTypes is completely > > haphazard; the mapping is designed to correspond to the entries in > > SpiderMonkey's js.msg, which my js.msg very likely will not match. > > > > * If one of my exceptions happens to have the same number as JSErr_Limit, > > a Bad Thing will happen. > > > > > > Yup, that's why I wrote asking for a bug to be filed. It's not a > missing feature (never said that); it looks like a design flaw, but > mccabe is not around any longer, and I didn't want to rush to judgment. Bug 215173. > 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. Braden .