docs: Document the behaviour in case of init failure

Or, better, the fact that the behaviour of any Clutter function will be
undefined in case the initialization fails.

The value returned by clutter_init() and friends has to be handled
properly.
This commit is contained in:
Emmanuele Bassi 2011-10-21 21:19:27 +01:00
parent 5f84c197b4
commit 5540e6bd9c

View File

@ -1814,6 +1814,10 @@ clutter_get_option_group_without_init (void)
* error message will be placed inside @error instead of being * error message will be placed inside @error instead of being
* printed on the display. * printed on the display.
* *
* Just like clutter_init(), if this function returns an error code then
* any subsequent call to any other Clutter API will result in undefined
* behaviour - including segmentation faults.
*
* Return value: %CLUTTER_INIT_SUCCESS if Clutter has been successfully * Return value: %CLUTTER_INIT_SUCCESS if Clutter has been successfully
* initialised, or other values or #ClutterInitError in case of * initialised, or other values or #ClutterInitError in case of
* error. * error.
@ -1951,6 +1955,11 @@ clutter_parse_args (int *argc,
* yourself, you can use clutter_init_with_args(), which takes a #GError * yourself, you can use clutter_init_with_args(), which takes a #GError
* pointer.</note> * pointer.</note>
* *
* If this function fails, and returns an error code, any subsequent
* Clutter API will have undefined behaviour - including segmentation
* faults and assertion failures. Make sure to handle the returned
* #ClutterInitError enumeration value.
*
* Return value: a #ClutterInitError value * Return value: a #ClutterInitError value
*/ */
ClutterInitError ClutterInitError