> It seems to me that we're talking about two different things:
>
> 1) Getting extended generic information about a type of error
> given the nsresult code.
> 2) Getting specific information about the currently pending
> error.
>
> For '1' there is a discussion of how this might be done by
> declaring nsresults in xpidl and human readable strings in
> resource files. This is in -
> http://bugzilla.mozilla.org/show_bug.cgi?id=13423 - No one has
> signed up to implement this or any other such plan. I think we
> should figure out how to get this done sometime soon.
Ah, yeah I am not so very concerned about this aspect. While it would be
nice, it might also be sufficient to just have a small database of known
nsresults and their corresponding mappings. I dunno, but this is what
Microsoft did with HRESULTs and their builtin FormatMessage function. The
ability to include these in the IDL file might be a superior solution but
you still have to worry about translation and all that. Another possibility
would be to have a service or something which operates through the standard
IDL stuff that contains a builtin database of error strings that you can
then register your own error strings with. The bad parts about this is that
it would be harder to use, and more error prone.
I think as programmers though it would be nice to have a solution for this
so we don't always spend a lot of our time trying to figure out the meaning
of the result 0x800F8723.
>
> For '2' we had some discussion in an Architecture meeting some
> time back and the consensus seemed to be "That would be neat, but
> do we really need it for what we are trying to accomplish?".
> There are various ways to attack this, but mozilla-the-browser
> can live without all of them. FWIW, xpconnect does its own
> tracking of errors/exceptions using thread-local-storage because
> it wants to be able to propagate exceptions across language
> boundaries - even JS -> C++ -> JS so that an exception thrown in
> JS can be caught in JS even with intervening C++ stack frames.
> But, it seemed that we did not want to incur the overhead (and
> code bloat) of doing such tracking at every place in the C++ code
> where error results are returned.
>
I guess I don't really understand this. I just want to be able to do as you
stated above in your definition of 2). If I call a method on an interface
say nsresult result = pFoo->DoStuff( ); and it returns a failure state (by
setting the high bit). Then it would be cool if I could get more interesting
error information out of there. I think that a standard method to do this
would be to use the normal XPCOM stuff and provide an error interface that
you retrieve somehow (whether you get it from the interface which errored,
or the erroring interface logs that error somewhere.) Then JavaScript
implementing an interface could have an error and my C++ code which found
the error could then print out something useful to the user (assuming an
unrecovereable error.) Using this same example but with say Python calling
into C++, the Python XPCOM layer would figure out that an error had been
returned and then could query for this standard interface (regardless of the
language on the other side, C++, JavaScript, Python, whatever) and then
formulate a Python specific exception which provided the information
returned. I think by using this concept of error handling instead of
something specific to xpconnect which only works with JavaScript (I'm not
totally sure about this, this is my interpretation of what was stated
above.) allows for a more language agnostic view of error handling. It would
make it less efficient to pass exceptions from one JS layer to another in
the JS -> C++ -> JS example you describe above (since the error information
would have to be effectively retransmitted at each language barrier) but
exceptions are intended to be just that, so I don't see this as being a bad
thing. Now after having ranted on like that I'm imagining this is not going
to make much sense. Does it?
> This is Open Source, so.. If you really need this then file a bug
> against xpcom and detail the strategy you have in mind. Announce
> the bug here and interested people can follow it and participate
> in the discussion. Then do the work (or convince someone else to
> do the work) and attach a patch. If this all results in a code
> change that the module owner things makes sense for the code base
> then it goes in. It may be that a change does not make sense for
> mozilla-the-browser, but is still worth having. Then it might go
> in with #ifdefs or using some other mechanism to make its use
> conditional.
>
> John.
So I must admit I have never thought I needed something bad enough to
justify this sort of thing, but I do think that with this error interface
(particularly because I only really care to have the interface become a
standard, the JavaScript and such usage of the interface does not have to
happen anytime soon as far as I am concerned...) I was wondering if you
could point me to a document or something which would help me through this
process. I'd be happy to do the work for it, I've just never done this
before.
Ken
