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
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
