The Truncation Trap and Its Steely Implication
The Truncation Trap and Its Steely Implication
There can be many reasons for failures, but I’d like to discuss one that probably isn’t thought of and fortunately has an easy solution: the truncation trap.
Join the DZone community and get the full member experience.Join For Free
Container Monitoring and Management eBook: Read about the new realities of containerization.
Staring quizzically at her phone, she sees something wrong. The numbers: They can’t be right. Something is wrong here. Meanwhile, far away, deep in the supporting code, a digit was lost.
How Did It Happen and How Can We Avoid It?
The experience described above is one we have all had. We’re trying to accomplish something such as ordering a product, checking a balance, proceeding through the checkout process, etc., directly in a browser or through a mobile app — and suddenly it fails. What we don’t know is what happened behind the scenes, and we really shouldn’t have to. The consequences are that the user loses confidence and considers moving their business elsewhere. There can be many reasons for these failures, but I’d like to discuss one that probably isn’t thought of and fortunately has an easy solution.
The Truncation Trap
The possibility for high-order digit truncation in coding is something we don’t pay enough attention to, but perhaps we should. High-order truncation occurs when a field that is a set size, say seven digits long, is moved into a field that is smaller, say five digits, resulting in the elimination of higher-level digits. This can occur during a straight move or assign, but more often, it slides in during a computational statement where the result field is not large enough to handle the largest possible result. This is different from truncation due to rounding. Throughout our code, we can inadvertently plant these little mines that could blow up one day. Why is this even occurring?
Historically, the storage allotted to programs was small. When some of these programs were written, they had less memory available than your smartphone has today. Because storage was so tight, developers were forced to make educated guesses about what sizes would work; not wanting to afford more storage than was absolutely necessary. We assured ourselves the result would never be that big. our theory proved correct during test — and for a few years in production — but ultimately, the result became too big, producing the scenario above. Even when storage restraints were relaxed, this practice of being conservative with storage continued. It’s true that these sleeping issues may never occur, but why take the chance in your code? When writing code, you need to consider that it may last decades. Plan for it to expand, and give it the size it needs.
How to Spot and Handle Truncation
Compilers will alert to cases of possible high-order truncation, but these warnings are often ignored. You might get assurances that it will be okay, but why take that chance? I suggest you ensure there are none of these warnings in the code as part of your production turnover procedure. One safety net is the ability to check for and handle size errors. You could use that, but putting in error handling is simply acknowledging that you know there could be a problem. What happens if and when the error occurs? Will the error be passed along to the end user, and how are they expected to deal with it? Instead of taking the time to put in error handling, just provide the right space for the data at the start. Planning for the error is really avoiding the issue. It’s much better to avoid the problem altogether.
So, you’ve passed on error handling and you’ve instead instituted good coding practices, but what about testing? Make it a standard part of your testing to run through calculations with maximum values and make sure the results are correct. Testing should always contain a test case with maximum values in the input data, no matter how ridiculous they may seem.
The Debugging Challenge
In cases where testing with maximum values hasn’t been done, consider the debugging challenge. What is the state of your current code base? How many cases of truncation do you have out there? What is your exposure? These types of errors can be very difficult to resolve. If they abend, then you at least have a starting point, but you will still have to trace the flow back to the origin. Even worse are examples like I referenced at the start. There is no abend and there's no hint of where it originated — there's just the wrong number. You will have to trace through the chain of programs, usually across platforms, and once the right program is found, you will have to go deep into the code. From there, you have to follow all the calculations to spot exactly where it went wrong.
This is a time consuming, disruptive and downright painful process that can be avoided. You know what else can be avoided? Puzzling a consumer who is on the other end of the code, trying to make sense of numbers that are nonsensical or a confusing error message. In both cases, she is inconvenienced and she’s likely lost trust in your company. Today, space is not the issue; we are more concerned with availability and accuracy. You need to be aware that there may be programs in your portfolio that could have this issue. So before you place more on your existing code, examine it for truncation errors.
Published at DZone with permission of Mark Schettenhelm , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.