Backwards compatibility!

Arrrrrrrrg!

As I said, I have made a nice new decimal maths library and am using it in one of my bits of code.

It was a simple update. The original code evaluated a simple sum and provided an answer. It was a tad quick and cheerful (a bit of a bodge) but worked well enough until recently. The new code does the same but using my new library.

What could go wrong - it was a function to evaluate a text decimal sum, simple as that. How hard could it be?

The original function just added and subtracted. It worked out how many decimal places were in play and did integer maths to that precision and printed result to that many places. I said it was a bodge.

This meant, as a fluke of the way it worked, 1.00+2 would be 3.00. I.e. the number of places in the output was dependant on the max number of places of the arguments. This was never a documented feature, but guess what, people were assuming it would work like that. This is in spite of output formatting for money to two places which is what I was using in my stuff.

Then we get the fact the old code allowed blanks for operands and treated as 0. Again, a fluke of the original code and not a documented feature, but once again, they were relying on it.

It is infuriating having to make special cases in code to reproduce old and totally undocumented side effects in some function just to keep users happy! I suspect that even if the manual had said "You cannot assume a specific number of decimal places in the output" and "Behaviour for an input that is not a well formed numeric expression is undefined and cannot be relied on" it would not be any different. Users are like that!

I am waiting for the next thing, but I have a feeling it is a side effect of the total lack of error handling and syntax checking in the earlier bodged code. I might end up refusing to fix what happens when total garbage is thrown at the function and insist they fix their use cases. We'll see how bad it is.

Arrrrrrrrrrrrg!