generated UNO code for service constructors

[Stephan Bergmann]

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.

Stephan