Introducing NaroAssert

This is another technical post, but will try to be as simple as possible.

NaroCAD did work hard to find a proper balance between extensibility and enforcing. For example you can add anything to any node as long as the code is enforced by generics when we talk about how data is stored in a document. When you work with geometric functions, you can add them with fairly short code but in the same time you can define fairly complex shapes (like Cut one). On the other hand, if you do insert by code wrong data, an exception is thrown and the developer will be able to track the problem fairly easy.

This concept of enforcing is named: programming by contract if is used at the runtime level, or compiler-based checking. The compiler-based checking is much better as you cannot do mistakes by design. But compiler-based checking will make some areas of code impossible to be written.

One of those areas is the Actions framework. One of the key ideas of it is that when you click on an action from toolbar, the action can ask for anything, and the framework will provide. But on the other hand, as the action can get anything (to be as extensible), you will never know what you will get. As a proper direction of developing NaroCAD will get that some areas can be interchanged, some hidden problems may appear, that are hard to debug, because someone that does not understand NaroCAD completely, will not all cases right.

Here comes NaroAssert, which is a "programming by contract" class, that is done to improve bug prevention issues. You will write your checks, similar with NUnit conditions, and you will get an exception of the assertion will not fit your expectations.

I've also applied those assertions on the NaroCAD's Actions framework. Those checks were like: if an action asks for an input, should not be able to ask for it twice. This will enforce, by design that a people will know which resources will ask and why. Another area that is improved, is that is enforced to do hijacking of actions or inputs. At the code-level if someone will write its activation code for switching an action, as happen in the CommandLine view, this action should close nicely this action (found and fixed bugs in this area too).
What about users? Should they "pay" for those developer like checks, that even they will happen, they may not be that affected: for example, if by mistake the previous action is not cleaned up properly, if the user will press escape, NaroCAD will get back to a stage that things again work, Another case is that if a cautious developer will check anything that is right, the application may run slower, as those checks will get some CPU time. So, if an exception is thrown, the user will get a crashed NaroCAD. So for this reason, NaroAssert will work only on developers' builds.