generated UNO code for service constructors
Noel Grandin
noel at peralex.com
Fri Feb 15 01:35:36 PST 2013
On 2013-02-15 11:24, Stephan Bergmann wrote:
> On 02/14/2013 02:54 PM, Noel Grandin wrote:
>> I just ran into a weird bug where I could see that the service was being
>> correctly instantiated, but then as a traced it back up the call tree,
>> the reference was suddenly empty!
>> (https://bugs.freedesktop.org/show_bug.cgi?id=60804)
>>
>> That was because of the generated UNO code for the service constructor
>> in FilePicker.hpp:
>> (note that I've simplified it a little)
>>
>> static Reference< XFilePicker3 > createDefault(Reference<
>> XComponentContext > const & the_context) {
>> assert(the_context.is());
>> Reference< XFilePicker3 > the_instance;
>> try {
>> the_instance = Reference< XFilePicker3 >(
>> the_context->getServiceManager()->createInstanceWithArgumentsAndContext(
>> "com.sun.star.ui.dialogs.FilePicker" ,
>> Sequence<Any>(),
>> the_context),
>> UNO_QUERY);
>> } catch (RuntimeException &) {
>> throw;
>> } catch (Exception & the_exception) {
>> throw DeploymentException( "component context fails to supply
>> service FilePicker of type XFilePicker3: "
>> + the_exception.Message, the_context);
>> }
>> if (!the_instance.is()) {
>> throw DeploymentException( "component context fails to supply
>> service FilePicker of type XFilePicker3" ), the_context);
>> }
>> return the_instance;
>> }
>>
>>
>> Perhaps we should be making it use the constructor form Reference<X>(..,
>> UNO_QUERY_THROW) ?
>>
>> Or perhaps we can change the error message in the last block to:
>> throw DeploymentException( "component context supplied a service
>> FilePicker, but the service does not implement interface XFilePicker3"
>> ), the_context);
>>
>> Which would be less confusing to my rather tired brain.
>
> ...but wrong in general, given that
> createInstanceWithArgumentsAndContext could already have returned a
> null reference.
>
> The current design (incl. UNO_QUERY instead of UNO_QUERY_THROW, which
> would lead to a RuntimeException "unsatisfied query for interface of
> type com::sun::star::ui::dialogs::XFilePicker3!" that would IMO be
> less useful as it would be more generic) was carefully chosen to give
> correct and useful information. But YMMV, of course.
Then how about this?
Split the logic so we can differentiate the cases.
Also, we could reduce the compress the EXE size a little by moving all
of this boilerplate into a central utility method somewhere.
static Reference< XFilePicker3 > createDefault(Reference<
XComponentContext > const & the_context) {
assert(the_context.is());
Reference< XInterface > the_instance1;
try {
the_instance1 =
the_context->getServiceManager()->createInstanceWithArgumentsAndContext(
"com.sun.star.ui.dialogs.FilePicker" ,
Sequence<Any>(),
the_context),
} catch (RuntimeException &) {
throw;
} catch (Exception & the_exception) {
throw DeploymentException( "component context fails to supply
service FilePicker of type XFilePicker3: "
+ the_exception.Message, the_context);
}
if (!the_instance1.is()) {
throw DeploymentException( "component context fails to supply
service FilePicker of type XFilePicker3" ), the_context);
}
Reference< XFilePicker3 > the_instance2( the_instance1, UNO_QUERY );
if (!the_instance2.is()) {
throw DeploymentException( "component context supplied a
service FilePicker, but the service does not implement interface
XFilePicker3" ), the_context); }
return the_instance;
}
Disclaimer: http://www.peralex.com/disclaimer.html
More information about the LibreOffice
mailing list