At 08:23 11/01/2001 -0600, Ken Kozman wrote:
> > 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.
The current nsErrorService implements providing strings for passed
nsresult, it depends though on the relevant component registering its error
strings and keys. At the moment there are only two components that
actually register their error strings and that's nsIOService and
nsFTPService. And no its not easy to localise so it is an interim measure
only. Personally, it seems to make more sense to place error messages into
an rdf that can be shipped with the component rather than build it into the
idl.
Its a laborious but trivial task to add the registering to any component
using xpcom if you let me know which specific components are important at
the moment I can spend some time plugging them in. I can't answer though
for how long it would take to get the diffs reviewed and into the tree.
> >
> > 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.
I think the case defined in 2) by John above is more about an ErrorService
reporting to clients that an error has occurred, whether or not that client
caused the error. In other words, the ErrorService is called by one or
more clients to register that they would like to know when any error (or
perhaps a class of error), occurs. Those clients could be Supervisory code
managing many threads or it might just be an observer type connection. In
that case everytime an exception was raised (oops smack hands), rather an
error was returned it would be copied to the ErrorService which would then
pass it on to any of its registered clients.
Of course I could be completely wrong, but that's how I read it.
Simon
>Ken
===============================================
The more exotic the Project name the more ordinary the Product
S.P.L.
