Re: warning about invalid tree model iterators

[Tim Janik <timj imendio com>]

On Sat, 18 Feb 2006, Owen Taylor wrote:

> On Fri, 2006-02-17 at 19:52 +0100, Tim Janik wrote:

> > i admit that artificial cases where checking the return value is not
> > required are easily created, but the actual harm involved is just a
> > mild annoyance. that is in contrast to forgetting to check the return
> > value which in practice easily happens, and requires significant debugging
> > work (possibly involving multiple persons, triggering of specific code
> > paths, etc.).
> > that, in combination with the fact that in most cases you ought to
> > evaluate the return value of the tree_model_iter functions anyway, leads
> > me to believe that allowing the compiler to catch omissions early in the
> > development process is going to be the less painful way and produce
> > the more robust code.
[...]

> In the end I don't really care about this a whole lot ... as you say,
> you are normally checking these returns anyways.
>
> I just wanted to point out the connection to error handling in general.
> In order to provide an error return at all, and certainly in order
> to force the programmer to check it, two conditions must be met:
>
> A) The error must be triggered by conditions outside the programmer's
>    control. (gtk_widget_show() should not return an error if the
>    programmer passes in NULL.)
>
> B) There must be some sensible recovery that the programmer can
>    do. (gtk_widget_show() should not return an error if a font file
>    on disk can't be opened so the widget can't be shown.)
>
> GTK+ shouldn't follow the road of some parts of the Java API's,
> where checked exceptions force you to write:
>
> try {
>    reader = new InputStreamReader(instream, "UTF-8");
> } catch (UnsupportedCharsetException e) {
>    throw new RuntimeException("WTF, UTF-8 isn't supported???", e);
> }

i've found this particular java requirement to be exceptionally
annoying as well ;)

> Anyways, I just wanted to throw a little note of caution in about
> G_GNUC_WARN_UNUSED_RESULT... I don't really remember the TreeModel
> interfaces well enough at this point to say whether it's 1% or 20%
> of the time where you don't need to check the result.

i agree that G_GNUC_WARN_UNUSED_RESULT shouldn't be added blindly all
over the code. i think i have made a sound case for the tree iterators
though, so unless i get objections from the folks who really know
the API well (jrb, kris), i'll apply the patch later this week, at the
option of backing parts of it out again if we really find it to be
a significant annoyance, contrary to current expectations.

> Regards,
> 						Owen

---
ciaoTJ