Lotusscript TimeDifference & Long data type - Grrr....

Spent Friday investigating some freakish code problems. This one just blew my mind....

When assigning numbers to a data type what do you expect to happen when you assign a number to big to fit the assigned data type? Right, an overflow error. 

Well explain this then....

Ok, yes I know, you can solve it by using "difference# = notesDateTime.TimeDifferenceDouble( notesDateTime )" method which will return a double. I just can't get my head around the fact that it didn't return an error when it overflowed on 2,147,483,647 and instead continued up from it's negative boundary (-2,147,483,648).
Or is this normal behavior for a Long data type??  I just hate it when I can't logically explain something...

Code I used to test the effect:

Sub Click(Source As Button)
    Dim todayD As New NotesDateTime(Today)
    Dim AlteredDate As New NotesDateTime(Today)
   
    Set todayD = New NotesDateTime(Today)
    todayD.Localtime = todayD.Dateonly + " 00:00:00"
   
    Set AlteredDate = New NotesDateTime(Today)
    AlteredDate.Localtime = AlteredDate.Dateonly + " 00:00:00"
   
    For x = 24850 To 24860
        Set AlteredDate = New NotesDateTime(Today)       
        Call AlteredDate.AdjustDay(-x)
        If TodayD.Timedifference(AlteredDate)<0 Then
            'EXPECTED OVERFLOW ERROR AT 24857 NOT HAPPENING

        End If

        Print "TimeDifference between: " + TodayD.DateOnly + " and " +_
        AlteredDate.DateOnly + " = " + Cstr(TodayD.Timedifference(AlteredDate)) +_
        " ---- Days: " + Cstr(x)       
    Next

End Sub

Update: I got this answer back through Twitter: "@FemkeGoedhart normal behavior for int/long. See http://en.m.wikipedia.org/wiki/Integer_overflow" Thanks @Thimo! It explains it, although the logic of Lotusscript returning an error on overflow of Integers but not on Longs still eludes me....

We all make mistakes

Last Friday I was working at a customer where I had to Copy & Paste some person document's into a secondary address book. Every time I attempted to do it the process would hang and simply wouldn't stop unless I manually broke it off (CTRL + BREAK). Now I had to paste about 600 records so this was not good news. After some investigation I found the culprit in the "(RenamePastedAccounts)" agent that had an infinite loop in it.

Now this agent is really, really simple. It loops through all the pasted documents and simply checks for a specific value in a field. If found it does something to that field and goes to the next document.....
Right, so do you see the mistake there?
If the value is NOT in the field it will never go to the next document, effectively doing the same check on the same document over and over again.

 While Not doc Is Nothing
        If 'value in field' Then
            ....
            Set doc = dc.getnextdocument(doc)
        End If
  Wend

It was easy to solve (just move the line that sets the document outside of the If clause) but I just couldn't help but chuckle. I think it demonstrates a fundamental flaw in development when it comes to testing. We've probably all done it. The difficult work you test and have tested but that simple procedure, that so easy to code action...... You know what it needs to do, you know how to do it and you are so confident about what you're doing that you forget to test it.... thoroughly.

So even at Big Blue, with all it's checks and testing this can happen it seems. Just glad it's not my name in that agent, knowing it will be distributed in hundreds of thousands of Domino environments, inevitable found and blogged about on sites around the globe and causing SPR's to be opened and Technotes to be published...... It's there for the world to see and there's nothing you can do but pray everybody upgrades before they ever run into it. And until it is corrected in a new version that honestly simple, stupid mistake will haunt you forever.
 
Ana......I feel for you.

Coming from someone that only last week managed to literally bring down a (test) server with a similarly simple and obvious coding mistake.