(Subject change since this is no longer directly relevant to this particular code review.)
David Bustos wrote: > I agree for interfaces across binaries. I disagree for function calls > within a file, since I think it's reasonable to expect a programmer who > adds an error code to change the callers in that case. It's not clear > to me that there's a good generic answer for calls across files of the > same binary. I think there's a continuum, much like the ARC stability continuum. The more work it is to change in sync, and the higher the likelihood that you will want separate deliveries, the more you need this kind of insulation. Personally, I apply layering, information hiding, future-proofing, and stuff like that almost as much on my internal interfaces as on my external interfaces. Sure, it's a lot easier to change internal interfaces in sync, but OTOH I'm lazy and don't want to *have* to; I want to be able to change a routine without necessarily having to change the routines it interfaces with. Looking at it another way, any routine is likely to have at least one error case where the caller will have to throw up his hands and say "heck if I know what to do"... so why not do that for all "unknown" error cases? (Again, with the architectural note about the desirability of hierarchical error reporting.)
