Ken Kozman wrote:
>
> I hate to add in a "me too" on this, but the project I am currently working
> on at my company is also in desperate need of some sort of common/standard
> rich error handling.
>
> For my intents I would be happy if there was just a standard interface
> agreed upon. But it would probably be even better if the mechanism for
> retrieving that information on an error per error basis was standardized as
> well.
>
> So does anyone know of certain people that we can perhaps contact to have
> this addressed?
>
> Ken
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.
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.
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.
