Mark Hammond <[EMAIL PROTECTED]> wrote in message > Check out nsError.h. Like MS-COM, it defines that some result codes are > errors, and some are not. All codes with the MSB set are considered > errors. From that .h: > > #define NS_FAILED(_nsresult) ((_nsresult) & 0x80000000) > #define NS_SUCCEEDED(_nsresult) (!((_nsresult) & 0x80000000))
Thanks for your response. Yes, I did look at nsError.h, and saw how the two are differentiated. I guess the question I'm asking is more one of form and suggested practice than one of how the macros work. What I haven't been able to tell is _when_ one should define a return value as a success versus as a failure. Outside the mozilla source, the best explanation I've found is John Bandhaur's http://www.mozilla.org/scriptable/interface-rules-we-break.html, and that has left me more confused. Users are expected to interpret a return value of NS_OK to mean one thing and any failure code to mean another. This pattern also will break down when used in XPConnect or across a proxy. The proxy uses the failure code for its own purposes and the intended result may not be passed through as expected. Don't do this. Use out params. I certainly understand that one should not try to coerce non-result codes into an rv, but I'm not sure what this means about the reliability of rv's. I could be reading this out of context, but it sounds like an admonishing of reacting differently to different error values. Does this warning mean that a proxy is entitled and justified in changing one NS_FAILED(rv) to another, and a caller should not rely on receiving the specific rv returned by the callee? > Thus, it is important that you use NS_FAILED() and NS_SUCCEEDED() rather > than explicitly checking for non-zero. NS_OK is but one "success" value. So is there a suggested guideline for what should be considered a failure and what a success? There seem to be very few cases of NS_SUCCESS_CODE values in mozilla. Is this a conscious design practice or just way things turned out? > On the other hand, Python will currently lose this nsresult value - the > bindings throw the value away if it is not an error code. This is getting much closer to what I'm looking for: it sounds a lot like a suggestion that one should currently avoid relying on specific non-error result values, at least if you want to play nice with Python. Is this how I should interpret it? Thanks!
