Re: g_try_new and g_try_new0 + error reporting for g_object_set
- From: Matthias Clasen <mclasen redhat com>
- To: Stefan Kost <ensonic hora-obscura de>
- Cc: gtk-devel-list gnome org, Stefan Kost <kost imn htwk-leipzig de>
- Subject: Re: g_try_new and g_try_new0 + error reporting for g_object_set
- Date: Tue, 08 Mar 2005 10:51:43 -0500
On Tue, 2005-03-08 at 16:25 +0100, Stefan Kost wrote:
> As the mail remained uncommented, it has now been posted under
> http://bugzilla.gnome.org/show_bug.cgi?id=169611
>
> Stefan
>
> Stefan Kost wrote:
> > hi hi,
> >
> > is there a reason why we dont have g_try_new and g_try_new0.
g_new and g_new0 are just convenience macros, and glib generally doesn't
try to handle oom situations. It should be easy enough to write your own
try_new() macro if you need it.
> >
> > Why I am asking? We use g_new a lot in our code. Recently we have added a helper
> > method to our unit-tests that goes over gobject properties of a given instance
> > and does read/write checks.
> > This triggered a 'problem'. For one class there is a property denoting the size
> > of a data-structure (number of slots). One can write to this property and then
> > the datastructure will adapt its size.
> > On one hand we do not want to limit the size more than neccesary, so the number
> > of entries is a g_ulong. The unit-testing code now tried to set the property to
> > the largest ulong and this caused it to abort, as g_new0 wasn't be able to
> > allocate that much. Now here would would rather like to notifiy the user that we
> > were not be able to perform that operation, than just aborting.
> > Therefor the need for g_try_new0.
> >
> > The second thing is how does one report that a g_object_set failed? All I can
> > currently think of is an error-property in the object, which the caller can
> > connect a notify handler on and retrieve the GError object in case of a problem.
> >
I think a property setter which can fail is a very bad idea. Properties
declare their allowed values, so you can avoid feeding them bad values
in the first place.
Matthias
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]