[Bf-committers] Re: Some words about a strange thing named "coding-rules"

[Yomgui]

Sure! It's depend on the "functionnal" usage to know how to handle an exception.

But we are melting two think here: generate an error (or exception, as you want)
and handle the error.

The main issue for me, it's that too many developper don't let upper
layers the chance to handle an error.
I don't say here that an error must be transported between all layer
from bottom to top.
Each layer should have to decide it. But lowest layers have not to
block it at start!
malloc() (or MEM_MallocN(), it's at the same level...) is a lowlevel
function. This is why it answers by a NULL pointer in case of error,
and why it DOESN'T do an exist() (or any other weird solutions).
After that we have to decide if the layer that uses this malloc()
should carry about NULL or not. There are no general rules, but the
best ones is to 'group' errors trought layers (low to high).

Now in our case, for an example as the rendering engine, the 'logical
way' of an 'fatal error' as not suffisent memory error is to stop the
rendering, freeing resources taken by it and return to the normal
usage, no? And for a thing like 'during a vertex move', a fatal error
should be reported to the application layer (and maybe that the
decision here will be to exit).

I don't want push you in a general and unique method. But I don't want
a code where some pretty lowlevel layer don't let us the choice about
how exceptions are handled.

For me it's at the application level that decisions should be done.

What 'll you think if freetype library cause the exit of your
application just because it cannot open a specific .ttf font? We are
closer of that...

PS: PNG it's not a so well-designed... there are some bad guys like
setjmp()! :-DD

Regards,
GR

> From: Jonathan Merritt <j.merritt at pgrad.unimelb.edu.au>
> Subject: Re: [Bf-committers] Re: Bf-committers Digest, Vol 16, Issue
>         47
> Yomgui wrote:
>
> >3. just put an "if (malloc == NULL) { handle null pointer }"
> >There are not so malloc() in the code... ;-)
> >You've already done much complexe things in past, no ? ;-)
> >
> >
>
> Of course - I knew I was missing something! :-) :-) :-)
>
> The issue here is that the blocks you refer to normally look something
> like this:
>
> z = malloc(N);
> if (z == NULL) {
>     /* free x */
>     ...
>     /* free y */
>     ...
>     return NULL;   /* or FALSE, or whatever */
> }
>
> The list of things to free increases as you progress through your
> mallocs().  Take a look at well-written code that uses image libraries
> (PNG is a great one) for examples of this.
>
> The calling function then has to check for a failed return as well, and
> must proceed to unwrap and free all of its resources, before passing the
> failed result up to ITS caller,  which has to do the same thing, etc...
>
> Now, for atomic events - things that are triggered in response to a
> direct user input and have clear-cut consequences - the desirable
> behaviour is surely to inform the user that their command could not be
> completed.  However, if a failure to allocate memory occurs in an event
> loop or somewhere else where it *should* really succeed, then unwinding
> everything and simply returning a "failure" to the caller is not always
> so simple.
>
> As a hypothetical example (I'm not sure of the code here, so I'm just
> guessing this could happen...), imagine that a memory allocation failure
> were to occur in response to a mouse dragging a vertex of a mesh, or a
> frame-change being unable to draw the scene in the new frame.  What does
> it mean for these actions to "fail"?  Surely these are situations (or
> others very similar) where there would be no recourse but for Blender to
> quit.  In these situations, a "malloc or die" function would be
> desirable, I think.
>
> Jonathan Merritt.
>
>
>
> ------------------------------
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
> End of Bf-committers Digest, Vol 16, Issue 49
> *********************************************
>