Re: g_try_new and g_try_new0 + error reporting for g_object_set

Hi Matthias,

Matthias Clasen wrote:
> On Tue, 2005-03-08 at 16:25 +0100, Stefan Kost wrote:
>>As the mail remained uncommented, it has now been posted under
>>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.
I am aware that I can write my own. But if many people do that it might make
sense to have them in the lib.

What do other do in this case?

>>>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.
Its more a consequence of the setter that fails ...
Every gobject that has a string property would abort, when the user sets a
string that is huge and the system runs out of resources ...
This is probably a very theoretical case, so just forget about it.

Thanks for answering.

      \|/            Stefan Kost
     <@ @>           private            business
+-oOO-(_)-OOo------------------------------------------------------ - - -  -   -
|       __  Address  Simildenstr. 5     HTWK Leipzig, Fb IMN, Postfach 301166
|      ///           04277 Leipzig      04251 Leipzig
| __  ///            Germany            Germany
| \\\///    Phone    +49341 2253538     +49341 30766101
|  \__/     EMail
|           WWW
===-=-=--=---=---------------------------------- - - -  -    -
fn:Stefan Kost
org:HTWK Leipzig;FB. IMN
adr:;;Postfach 301166;Leipzig;;04251;Germany
email;internet:kost imn htwk-leipzig de
title:Dipl. Informatiker
tel;work:+49341 30766440
tel;home:+49341 2253538
tel;cell:+49178 3183742

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]