Assertion errors – not only for devs

Hi,

So one difficult topic now. In his post I will throw around with things like precondition and code, but I really try to keep it simple.

So, let us first introduce the example. A “Linked-List”. What you need to know (just valid for this tiny example):

• No element –> NULL
• “->” is the link between elements
• No element is an element
• A list starts at “head”, so head is just the link to the first element

Let’s have an example. These are valid lists

1. head->null
2. head->1->2->3->null

The length of 1) is ZERO, of 2) THREE. That is most of the coding skills you need 😉

So, what are errors? You find them in LibreOffice as well as in all other software. It does not behave as expected, maybe resulting in a crash. That is quite obvious.  You can have invalid or simply unexpected input. As you can see in the above example, we do not expect to add the element “null” at position 1 [between 1 and 2] Would result in head->1->null->2->3->null (again sorry to all developers, I need easy examples).  So we are not allowed to add the element “null”, as this would result in changing the length of the list from 3 to 1, by adding one element. 3+1=1 okay, I guess that should not be like that…. So the code is a little bit inspired by Java, so sorry for the overhead 😉

public void addElement(int position /*A number from -2147483648 to +214483647*/, IntElement e /*Also a number like in our example, but it can have a link to a different IntElement*/){
assert e != null && LENGTH_OF_LIST >= 0;
if(head == null) //If we have an empty list
INSERTFRONT //We do not need to much detail here
assert LENGTH_OF_LIST == 1; //== means equals
return; //Exit the function here
}
int oLength = LENGTH_OF_LIST;
assert position >= 0 AND position <= LENGTH_OF_LIST;
INSERT_MIDDLE_LAST //Insert at the rest of the list
assert LENGTH_OF_LIST == oLength +1; // If adding succeeded the new length must be 1 greater than the old one
}

You can see some line start with “assert”. This are developer’s magic little helpers.

A function in mathematics and informatics has 3 conditions:

1. Precondition –> How should the input should look like
2. Post-condition –> How should the output / result of the function should look like
3. Invariance–> What should be valid at the beginning and the end

Invariance

What should be at the beginning and at the end?  The length must be >=0.

Precondition

The inserted element must not be NULL and the length of the list must be positive (So this includes the invariance as well)

Post-Condition

If the list is empty –> Length is 1 (this includes the invariance)
If the list is not empty the new length must be by one greater than the old length. (this includes the invariance as well)

So, did you get the need? You can assure yourself that the input and output of a function (and if you want steps inside) are correct. So you cannot get any unexpected result, if assertions are enabled. Assertions are disabled by default, because they slow down a bit, but in LibreOffice Daily build from tinderbox 39  (downloadable @ SI-GUI atm) assertions are enabled.

So finally, an example (I only realized they were enabled because of this message:

 

So at line 1291 of winlayout.cxx an assertion failed (while testing bug # 77248) That’s a starting point for devs. The error might be near there 😉 So yes, it makes sence to have assertions enabled and more to write them. If you write down how the output and the input should look like, everyone knows. You are turning implicit to explicit knowledge. And you will save hours to search for the place, where the error did occur. So please, and this is not limited to LibreOffice, have assertions enabled during testing!

And if you see such a dialog and remember the steps you did to come there, check if such a bug exists and comment with the exact version, or create a new bug. The exact version is needed, because this is the only way, that devs know on which version of the file they can find the failing assertion.