![Avoid letting your error codes become the new Blue Screen of Death [3:4]](https://gpower.io/wp-content/uploads/2026/09/Figur-1-Windows-11-Blue-Screen-of-Death-1.webp)
This post [3:4] is part of a series by GPowers software developer, Jesper Kjær Sørensen, on building robust software and test systems.
Do you know the feeling...?
There are three hours until the deadline for your assignment, and then it happens—the one thing that must not happen. Your computer shows a “Blue Screen of Death” and restarts spontaneously. After the restart, you can see that everything has been saved, and you got away with a scare. You can still meet your deadline, and everything is fine. But you are left with the questions: why did the error occur, and how do I avoid it happening again? In other words, you have encountered Windows’ way of translating the computer’s internal errors: the dreaded Blue Screen of Death! I am well aware that Microsoft has painted it black in Windows 11, but that is not important for this article.
![Avoid letting your error codes become the new Blue Screen of Death [3:4]](https://commons.wikimedia.org/wiki/File:Windows_11_BSOD,_build_22000.51.png)
In this third article in the series on error handling, we take a closer look at the process of translating internal errors into external errors across the API interface—where the infamous Blue Screen of Death is an example of how NOT to do it. To be clear: by “translation” I do not mean linguistic translation into another language, but translation into a different and more specific error code. We also look at some of the approaches you can use to good effect in your code. The article is based on the graphical programming language LabVIEW, but the practice of translating internal errors is also relevant for other programming languages such as Java, C#, and even Python. It is simply good programming practice.
Why should you translate your error codes?
Translating error codes is about several things. It should rather be seen as an active filtering of what is relevant to report onward.
If you do not translate your errors into API-specific errors, it becomes harder to troubleshoot where a generic error code originates. It could just as well come from the API-calling code as from your product API.
It increases the communication value to return a specific code that matches the API action the user attempted. If your API, for example, communicates with a web service to create a user there, it does not make sense to report the status code that the web service returns on error. The action your user is trying to complete is to create a user, so it should be translated into a specific “user creation” error. That error can then include parameters that make it easier for your user to troubleshoot, such as disallowed characters or similar.
Translating the error codes increases the coherence of your API, because the functions your API provides return a logical response. This response is important when your API executes successfully, but absolutely also when your API fails. Ideally, your API should not become the new “Blue Screen of Death” within your product category.
The benefits of error code mapping
Error codes are part of your API interface, and they help determine your API’s backward compatibility. This is another reason to translate your error codes into a more specific code. If the aforementioned web service changes its status code to a different one when a user cannot be created, what happens then? If you translate the web service’s error code, you can still translate to the same error code—whereas the other scenario results in breaking backward compatibility. In other words, this specific implementation fails when a different error code comes out of your API. Thus, translating error codes helps decouple your API from the service or measuring instrument it is built for. This gives you the freedom to change the underlying implementation without breaking backward compatibility. If you also need techniques for sorting error codes, you may want to take a look at my previous article on error handling.
You should only translate errors on the functions in the API interface. Translating error codes is always a trade-off in how granular your error codes should be. It can be tempting to translate all your internal errors into a single error, but that removes the communication value—just like the aforementioned Blue Screen of Death. Conversely, if each internal error is split into several different error codes, it becomes a problem over time to keep track of which errors are used in each function. Therefore, as a developer you must decide which errors can be reported back from each individual function that exists in the API interface. In other words, it is necessary to take a systematic approach.
GPower’s error code system
In LabVIEW, there is no class-based error code system like there is in, for example, Python, where you can inherit from a general LabVIEW error class. This is because LabVIEW Error Clusters existed before LabVIEW included support for object-oriented programming. Therefore, a convention has been established that all user-specific errors reside in one of the three ranges shown in Figure 2.
Creating your own error codes provides many possible combinations. There is no error description or code that adequately covers all the errors that may occur within your API. Therefore, it is important to group the errors in a logical way so that the error handling has a sensible structure. At GPower, we have created our own rule set for how developers at GPower create API-specific error codes: Only error codes between 5000 and 9999 are used:
- The four digits of the error code are divided into grouping and sequential numbering
- The first two digits represent the error group (50, …, 99)
- The last two digits are a sequential counter (00, 01, …, 99)
- All error codes are placed in a specific folder in each API
- An error code mapping is implemented in its own VI
- An error code VI has a matching icon so they are recognisable
- An error code must support multiple languages
- Error codes must support being called with different priorities without side effects
- Error code VIs are private to the API, but must be reusable internally where it makes sense
In other words, there are many considerations we have made around error code mapping for ourselves—and perhaps all or some of them may be useful to you?
By encapsulating the mapping in a VI, you gain the advantage that you can use all of LabVIEW’s search tools to find where the given error code is used. The error code mapping can also be reused if it functionally fits into another API function. There is no reason to create yet another error code for exactly the same function in the same API.
A very important point is that a VI for error code mapping is private to the API that implements it. This removes the possibility of reusing the same function across the interface between two APIs. When you think about it, that would create a strange dependency. It is better to create the VI with the same content and document it in the other API. If the first API then removes the error code, the other API will still work. Similarly, the developer should not synchronise the sequential number for the error code across APIs. Two error codes with the same number can exist in different APIs, as long as they exist in their respective libraries.
GPower Custom Error Assistant to help the developer
It can be overwhelming to keep track of all these elements when developing code, and therefore at GPower we have automated the creation of VIs for mapping the error codes, so that only the adjustment of the mapping remains. This is done via our internal tool, GPower Custom Error Assistant.
The assistant is built to ensure consistent solutions across internal APIs as well as customer projects. It automatically selects the next sequential number in the series of error codes within the category, and it also ensures that the error code is saved in the correct location. In addition, the assistant helps show which errors belong under the selected category. During creation, you decide which error code category you want to create and name the error code.
The result of an error 5500 can be seen in Figure 4 below. Note in particular that the number for the individual error mapping is also shown in the icon for this VI. If the error code requires specific parameters for troubleshooting, it is easier to modify the arguments that have already been created—or delete them. In addition, I can briefly mention that the template also includes built-in support for linguistic translation of error codes.
If we look at an example from our Application v2 package, where we have the function “”, it is easy to see how the error code is implemented—see Figure 5.
Any errors that occur inside the function are all mapped to error 5501 – “VI Property Error” with a parameter for the VI’s location on disk. In other words, no other error codes can come out of this function.
A concluding remark
With this article, you are now well equipped to create your own mappings from error codes to specific error codes. I fully understand that you do not have access to our GPower Custom Error Assistant or Application API, but these should primarily be seen as examples of how it CAN be done. It is not certain that all our rules will suit you, but choose the ones that work and make use of them. The most important thing is that you are consistent about it.
Before I wrap up, I will answer the open question you may be sitting with. You may think it is strange that there is only room for 100 error codes in each group. But if you need 100 unique error codes without reuse within your API, then there are other issues to address, such as modularising your code.
Please feel free to use the comments on LinkedIn if you have feedback or questions about the article.
You should ONLY translate errors on the API interface functions.
– LabVIEW Champion, Jesper Kjær Sørensen, GPower
![Avoid letting your error codes become the new Blue Screen of Death [3:4]](https://gpower.io/wp-content/uploads/2026/09/Figur-1-Windows-11-Blue-Screen-of-Death-1-300x225.webp)
![Error handling in LabVIEW [2:4]](https://gpower.io/wp-content/uploads/2026/06/Fejlhaantering-i-labview-jesper-kjaer-soerensen-gpower-300x169.png)
![Error handling in LabVIEW [2:4]](https://gpower.io/wp-content/uploads/2026/06/Fejlhaantering-i-labview-jesper-kjaer-soerensen-gpower.webp)