Hi Eike, >>> OTOH designing exceptions right is very hard and often needs a lot of >>> thinking. So I don't expect that we can fix that in a "big bang" >>> release, we will need quite some time to fix that. >> I would be happy if we would allow for such fixing. I don't want to fix >> all of those at the same time, but being able to fix them incrementally, >> as they bite me, would be great. > > Unfortunately, adding exceptions to a method changes the API contract, > so fixing things incrementally would incrementally destabilize API use.
what do you mean by destabilize? The only problem I see is that classes implementing the respective interface need to be adjusted, too, which of course is error prone. If this adjustment is not made, implementations throwing the new exception might crash (at least on platforms where the compiler respects the throw specification on a method, and generates code to assure it). Nonetheless, I think that's manageable. (Side note: If the tool generating our C++ headers would have the - long-desired - feature to create a ¨#define DECLARE_XFOO¨, then the problem would be less severe, as then a simple recompilation would adjust the headers, and the not-adjusted source files would simply break during compilation.) > We'll need some versioned API for this. I guess many are missing such > thing and didn't do useful but not required changes for just the reason > of API compatibility. Not sure we need versioning, but we definitely need to way to (carefully) break compatibility. As I've been told, this has been a topic on this week's engineering steering committee meeting ... Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
