generated UNO code for service constructors

[Noel Grandin]

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