{"id":23156,"date":"2026-09-09T11:37:45","date_gmt":"2026-09-09T09:37:45","guid":{"rendered":"https:\/\/gpower.io\/avoid-letting-your-error-codes-become-the-new-blue-screen-of-death-24\/"},"modified":"2026-09-09T13:44:09","modified_gmt":"2026-09-09T11:44:09","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":"Don\u2019t let your error codes become the next 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 GPower systems engineer Jesper Kj\u00e6r S\u00f8rensen on building robust software and testing 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

Does this sound familiar...?<\/h3>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

You have three hours left until your deadline, and then the one thing that must not happen happens. Your computer throws up a \u201cBlue Screen of Death\u201d and spontaneously restarts. After the restart, you discover that everything has been saved, and you\u2019ve had a lucky escape. You can still make your deadline, and all is well. But you\u2019re left with two questions: Why did the error occur, and how can I prevent it from happening again? In other words, you\u2019ve just encountered Windows\u2019 way of translating the computer\u2019s internal errors: the dreaded Blue Screen of Death!I\u2019m well aware that Microsoft has painted it black in Windows 11, but that\u2019s 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\"Don\u2019t\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 dive into the process of translating internal errors into external errors across an API boundary. The aforementioned\u2014and dreaded\u2014Blue Screen of Death is a prime example of how NOT to do it. Just to clarify: By translation, I don\u2019t mean linguistic translation from one language to another. I mean translating an internal error into a different, more specific error code. We\u2019ll also look at some systematic approaches that you can use to your advantage in your own code. The article is based on the graphical programming language LabVIEW, but the principles and practices involved in translating internal errors are equally relevant to other programming languages, such as Java, C#, and even Python. It\u2019s 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 serves several purposes. It should be seen more as an active process of filtering what is relevant to report further. <\/p>

If you don\u2019t translate your errors into API-specific errors, it becomes more difficult to determine where a generic error code originates. After all, it could just as easily come from the code calling the API as from your product API itself. <\/p>

Returning a specific error code that matches the API action the user attempted provides more meaningful information. For example, if your API communicates with a web service to create a user, it makes little sense to report the status code returned by the web service when an error occurs. The action your user is trying to perform is to create a user, so the error should be translated into a specific error related to user creation. That error can then include parameters that make troubleshooting easier for the user, such as characters that are not allowed or similar information. <\/p>

Translating error codes improves the consistency of your API by ensuring that the functions provided by your API return logical and meaningful responses. This is important when your API executes successfully, but it is just as important when your API fails. After all, you don\u2019t want your API to become the new \u201cBlue Screen of Death\u201d in 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 translation<\/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\u2019s interface, and they help determine the backward compatibility of your API. This is yet another reason to translate your error codes into more specific codes. What happens, for example, if the previously mentioned web service changes the status code it returns when a user cannot be created? If you translate the web service\u2019s error code, you can still translate the new status code into the same API-specific error code. In the other scenario, however, you have broken backward compatibility. Your error handling\u2014or more specifically, its implementation\u2014breaks when a different error code suddenly comes out of your API. Translating error codes therefore helps decouple your API from the service or measurement instrument it was built to work with. This gives you the freedom to change the underlying implementation without breaking backward compatibility. And if you need techniques for filtering error codes, I recommend taking a look at my previous article on error handling<\/a>. <\/p>

You should only translate errors in the functions exposed through the API interface. Error code translation always involves finding the right level of granularity for your error codes. It may be tempting to translate all your internal errors into a single error, but this removes their communicative value, much like the aforementioned Blue Screen of Death. On the other hand, if each individual internal error is split into several different error codes, it will become increasingly difficult over time to keep track of which errors are used by each function. As a developer, you therefore need to decide which errors can be reported by each individual function exposed through the API interface. In other words, you need 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 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

There are many possible ways to structure your error codes. No single error description or code can adequately cover all the errors that may occur within your API. It is therefore important to group errors logically to create a clear and meaningful structure. At GPower, we have established our own set of rules for how developers 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