{"id":23156,"date":"2026-09-07T14:37:45","date_gmt":"2026-09-07T12:37:45","guid":{"rendered":"https:\/\/gpower.io\/avoid-letting-your-error-codes-become-the-new-blue-screen-of-death-24\/"},"modified":"2026-09-07T15:28:51","modified_gmt":"2026-09-07T13:28:51","slug":"avoid-letting-your-error-codes-become-the-new-blue-screen-of-death-24","status":"publish","type":"post","link":"https:\/\/gpower.io\/en\/avoid-letting-your-error-codes-become-the-new-blue-screen-of-death-24\/","title":{"rendered":"Avoid letting your error codes become the new Blue Screen of Death [3:4]"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

This post [3:4] is part of a series by GPowers software developer, Jesper Kj\u00e6r S\u00f8rensen, on building robust software and test systems. <\/h2>\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Do you know the feeling...?<\/h3>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

There are three hours until the deadline for your assignment, and then it happens\u2014the one thing that must not happen. Your computer shows a \u201cBlue Screen of Death\u201d 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\u2019 way of translating the computer\u2019s 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. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\"Avoid\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t\t\t\t
Image 1: Windows 11 \u201cBlue\u201d Screen of Death<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

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\u2014where the infamous Blue Screen of Death is an example of how NOT to do it. To be clear: by \u201ctranslation\u201d 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. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t

Why should you translate your error codes?<\/h3>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Translating error codes is about several things. It should rather be seen as an active filtering of what is relevant to report onward. <\/p>

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. <\/p>

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 \u201cuser creation\u201d error. That error can then include parameters that make it easier for your user to troubleshoot, such as disallowed characters or similar. <\/p>

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 \u201cBlue Screen of Death\u201d within your product category. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t

The benefits of error code mapping<\/h3>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Error codes are part of your API interface, and they help determine your API\u2019s 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\u2019s error code, you can still translate to the same error code\u2014whereas 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<\/a>. <\/p>

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\u2014just 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. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t

GPower\u2019s error code system<\/h3>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

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<\/a> 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. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t\t\t\t
Figure 2: LabVIEW error code ranges for user-defined errors<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

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: <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t