Kay, Thorsten, please read carefully, I never stated assureNotNull() behaves differently when compiling with/without debug, just asserts or whatever. My point is that I prefer the throw-mimic being separated out into another function (if(!x.is()) throw RuntimeException...).
-Daniel PS: However that separate function may be called, we obviously shouldn't call it assureNotNull() which seems to be too close to the term "assert". :) Kay Ramme - Sun Germany - Hamburg wrote: > Daniel, > > I tend to disagree here, you are certainly free to rely on some > interfaces to be available, but you are _not_ allowed to just crash in > cases of unavailability, which, if I understand correctly, would / could > happen in case of using assertions. > > So, I suggest to go with UNO_QUERY_THROW stuff (or similar) anyway. > > Kay > > Daniel Boelzle wrote: >> Hi Frank, >> >> personally, I don't like those _THROW enums anymore and think I was >> wrong to add them some years ago. Sure, the need to enforce API >> constraints programmatically is still a valid point, e.g. a method >> returning a null reference though the API stated the returned ref is >> never null has to lead to a RuntimeException. >> But I rather would like this decoupled, e.g. >> >> Reference<foo::XBar> x(y->baz()[, UNO_QUERY]); >> assureNotNull(x); >> >> IMO more verbose, but clearer to read. >> >> my 2 cents, >> -Daniel >> >> >>> Hi, >>> >>> consider the following C++ code fragment: >>> >>> Reference< XFooSupplier > xSupplyFoo( xSomething, UNO_QUERY ); >>> Reference< XFoo > xFoo; >>> if ( xSupplyFoo.is() ) >>> xFoo = xSupplyFoo->getFoo(); >>> if ( !xFoo.is() ) >>> handle_very_serious_contract_breach(); >>> >>> Assume that both xSomething *not* supporting XFooSupplier, and xFoo >>> *not* returning a non-NULL foo is a serious breach of xSomething's >>> contract [1]. >>> >>> Now the above code is rather laborious to write. Since quite a while, it >>> could be shortened to >>> >>> Reference< XFooSupplier > xSupplyFoo( xSomething, UNO_QUERY_THROW ); >>> Reference< XFoo > xFoo( xSupplyFoo->getFoo() ); >>> if ( !xFoo.is() ) >>> handle_very_serious_contract_breach(); >>> >>> The UNO_QUERY_THROW here relieves us from testing xSupplyFoo for NULL, >>> since it will throw a RuntimeException when the interface is not >>> supported. Nice. >>> >>> Even shorter: >>> Reference< XFooSupplier > xSupplyFoo( xSomething, UNO_QUERY_THROW ); >>> Reference< XFoo > xFoo( xSupplyFoo->getFoo(), UNO_QUERY_THROW ); >>> >>> This relieves us from *all* checks: A RuntimeException will be thrown >>> whenever the contract of xSomething is not fulfilled. >>> >>> The crux here: Creating xFoo involves an additional, unnecessary >>> queryInterface call. Since those tend to be expensive, that's something >>> I'd like to avoid where possible. >>> >>> So, here goes my suggestion: What about introducing some UNO_SET_THROW, >>> whose usage would look like: >>> >>> Reference< XFooSupplier > xSupplyFoo( xSomething, UNO_QUERY_THROW ); >>> Reference< XFoo > xFoo( xSupplyFoo->getFoo(), UNO_SET_THROW ); >>> >>> , and which would only *set*, but not *query* for the given interface >>> type. This way, the original code fragment could be ultimately >>> shortened, by still keeping it as performant as before. >>> >>> Opinions? >>> >>> Ciao >>> Frank >>> >>> [1] Could we please, this time, refrain from the discussion whether it >>> is better to simply crash here when accessing the NULL pointer? >>> Thanks. >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
