Property grid, command line fixes and programming by contract

Because iteration is close to end, I had look on bug fixing, and the list seems smaller and smaller.
Property grid have a chance of potential crash because it scan string property instead of function name (and because we chose the same name, we did not encounter the problem, till I made a description that fails :) ).

Also there is a bug fix that is because when NaroCAD starts, the default shapes are shown as command lines adding unneeded verbosity and bogus command line list.

I had looking for a bug that "should not be there" and I found why the idea of "programming by contract" may be a solution for a class of problems. Programming by contract means that every time you will not have a corresponding parameter you will throw an exception. This is somehow a bad thing when user face it, so many programmers to not encounter problems, they do defensive programming: every time there is an argument not right, use a default, or return from function as nothing is gonna happen. The good thing of programming using "contracts" or "assertions" is that every time you throw an invalid value, is is seen to you as fast as you go.

As far as Naro is, most factories are implemented defensive, and today there was noticed a strange bug: Ellipse's property grid do nothing. I had make assumption that function do not work right. I had debugged function and seems to do all things right, also I had looked to property grid itself, some properties work fully right. I had debugged the changes in property grid, and notifications were there. The single problem was that changes were in a wrong place. We had a framework that works with contracts for Ellipse and if it were used, it would throw an exception, instead doing side effects you don't expect.

So, probably, it will be nice that even factories to work by contract, and the user who relate on them to be aware that they need to take the right thing. Is pretty bad code some like this:
IntegerInterpreter aib = label.Get<IntegerInterpreter>();
if(aib != null) ...
Probably the best code is always:
IntegerInterpreter aib = label.Get<IntegerInterpreter>();
aib.Value = 5; //throws exception

What would we do for cases that we need to check if there is a specific attribute there before accessing them?
if(label.HasAttribute<IntegerInterpreter>()) //previous code

Making things less defensive will decrease lines of code and will show more problems of your code easier. Also, will make code more expressive as you will not have to look on the code and to "skip" lines that are only checks that do almost nothing than ensure that there is really an integer there.