[Kst] Policy on asserts, checks, and other defensive programming.

[Barth Netterfield]

Hi,

Defensive progamming  (memory checks, code skipping, etc) should be used iff:
	-the thing being checked for could happen due to an action of the user or OS
		(eg, the user resizes a plot too small, or allocates 1E12 samples in a 
vector)
or	
	-a reasonable re-use of the code or reasonable changes elsewhere could 
generate the event
and
	-there is a reasonable strategy to cope with it.
		(eg, don't draw or don't accept...)

Examples:
	-Memory checking by the UI at vector generation is good, because we know what 
to do about it.
	-We won't do memory checking when routinely creating a small fixed size item, 
because linux currently doesn't let us do anything about it (cf, stack 
variables...)
	-Checking for 0 size pixmaps is good, because on some window managers, with 
some font sizes and icon sizes, the pixmap could end up zero size; and we 
know of a clean way of handling it (don't draw).

This is always going to be a judgement call, so:

If, based on this policy, a developer decides to put one in **while working on 
the code in question**, let them.  (if you add one, please leave a brief 
comment as to why it is there)

If, based on this policy, a developer decides to remove one **while working on 
the code in question**, let them.

Actual documented bug fixes are always allowed, of course, but to avoid 
sensless squabbling, please be specific about the behaviour you are changing 
when you make the change...
(eg, prevents a crash when the user .... or speeds up redraws by ....)

Thoughts?  Otherwise I will add it to devel docs.

cbn