![Undgå at dine fejlkoder bliver den nye Blue Screen of Death [3:4]](https://gpower.io/wp-content/uploads/2026/09/Figur-1-Windows-11-Blue-Screen-of-Death-1.webp)
Dette indlæg [3:4] er en del af en serie af GPowers softwareudvikler, Jesper Kjær Sørensen, om at bygge solide software- og testsystemer.
Kender du det...?
Der er tre timer til deadline på din opgave, og så sker det, som ikke må ske. Din computer melder en ”Blue Screen of Death”, og genstarter spontant. Efter genstarten kan du se, at alt er blevet gemt, og du slap med skrækken. Du kan godt nå din deadline, og alt er godt. Men du står tilbage med spørgsmålene, hvorfor skete fejlen, og hvordan undgår jeg, at det sker igen? Du er med andre ord stødt på Windows’ svar på oversættelse af computerens interne fejl; den frygtede Blue Screen of Death! Jeg er godt med på, at Microsoft har malet den sort i Windows 11, men det er ikke vigtigt for artiklen.
![Undgå at dine fejlkoder bliver den nye Blue Screen of Death [3:4]](https://commons.wikimedia.org/wiki/File:Windows_11_BSOD,_build_22000.51.png)
I denne 3. artikel i serien om fejlhåndtering dykker vi ned i processen om oversættelse af interne til eksterne fejl på tværs af API-grænsefladen, hvor nævnte og frygtede Blue Screen of Death er et eksempel på, hvordan man IKKE skal gøre. Så for lige at præcisere: Med oversættelse mener jeg ikke den lingvistiske oversættelse til et andet sprog, men oversættelsen til en anden og mere specifik fejlkode. Derudover kigger vi på nogle af systematikkerne, som du med fordel kan anvende i din kode. Artiklen er baseret på det grafiske programmeringssprog LabVIEW, men praktikken omkring oversættelsen af interne fejl er også relevant for andre programmeringssprog såsom Java, C# og sågar Python. Det er bare god programmeringsskik.
Hvorfor bør du oversætte dine fejlkoder?
Oversættelse af fejlkoder handler om flere ting. Det skal mere ses som en aktiv sortering i, hvad der er relevant at rapportere videre.
Hvis du ikke oversætter dine fejl til API-specifikke fejl, bliver det sværere at fejlfinde, hvor en generisk fejlkode kommer fra. Det kan jo lige så vel komme fra den API-kaldende kode som fra dit produkt API.
Det højner kommunikationsværdien at returnere en specifik kode, som matcher den API handling, som brugeren forsøgte sig med. Hvis dit API f.eks. kommunikerer med en webservice for at oprette en bruger på denne, giver det ikke mening at rapportere den statuskode, som webservicen returnerer ved en fejl. Handlingen, som din bruger prøver at gennemføre, er at oprette en bruger, hvorfor det bør oversættes til en specifik fejl om oprettelse af bruger. Den fejl kan så have parametre, som gør det nemmere at fejlfinde for din bruger, såsom karakterer der ikke er tilladt eller lignende.
Oversættelsen af fejlkoderne højner sammenhørigheden i dit API, fordi der kommer en logisk respons fra de funktioner, som dit API udbyder. Dette respons er dels vigtigt, når dit API eksekverer succesfuldt, men absolut også når dit API fejler. Dit API skal jo helst ikke blive til det nye ”Blue Screen of Death” inden for din produktkategori.
Fordelene ved fejlkodeoversættelse
Fejlkoder er en del af dit APIs grænseflade, og de er med til at bestemme bagud-kompatibiliteten for dit API. Dette er endnu en grund til at oversætte dine fejlkoder til en mere specifik kode. Hvis den førnævnte webservice skifter sin status kode til en anden, når en bruger ikke kan oprettes, hvad sker der så? Hvis du oversætter webservicens fejlkode, kan du stadig oversætte til den samme fejlkode, hvorimod det andet scenarie resulterer i, at du har brudt din bagud-kompatibilitet. dine fejl, fejler denne specifikke implementering, når der kommer en anden fejlkode ud af dit API. Dermed hjælper oversættelsen af fejlkoder til at afkoble dit API fra den service eller måleinstrument, som den er bygget til. Det står dig hertil frit for at ændre den underliggende implementering uden at bryde bagud kompatibiliteten. Hvis du i øvrigt mangler teknikker til sortering af fejlkoder, kan du med fordel kigge i min tidligere artikel om fejlhåndtering.
Du skal kun oversætte fejl på API grænsefladens funktioner. Oversættelse af fejlkoder er altid en afvejning af, hvor granuleret dine fejlkoder skal være. Det kan være fristende at oversætte alle dine interne fejl til en enkelt fejl, men det fjerner kommunikationsværdien ligesom den førnævnte Blue Screen of Death. Omvendt: Hvis den enkelte, interne fejl bliver splittet i flere forskellige fejlkoder, bliver det over tid et problem at holde styr på, hvilke fejl der bruges i hver funktion. Derfor skal du som udvikler tage stilling til, hvilke fejl der kan rapporteres tilbage fra hver enkelt funktion, som findes i APIets grænseflade. Det er med andre ord nødvendigt at gå systematisk til værks.
GPowers fejlkodesystematik
I LabVIEW er der ikke et klassebaseret fejlkodesystem, som der f.eks. er i Python, hvor man kan nedarve fra en generel LabVIEW-fejlklasse. Det skyldes, at LabVIEW Error Clusters eksisterede før LabVIEW inkluderede support for objektorienteret programmering. Derfor er der lavet en konvention om, at alle brugerspecifikke fejl ligger i et af de tre områder, som kan ses på billede 2.
Det giver mange kombinationsmuligheder at lave sine fejlkoder. Der findes ikke en fejlbeskrivelse eller kode, som fyldestgørende dækker alle de fejl, som kan opstå inde i dit API. Derfor er det vigtigt at gruppere fejlene på en logisk måde, så der kommer en fornuftig struktur i fejlene. Hos GPower har vi oprettet vores eget regelsæt for, hvordan udviklere hos GPower laver API-specifikke fejlkoder: Der bruges kun fejlkoder mellem 5000 og 9999:
- De fire fejlkodecifre er inddelt i gruppering og fortløbende nummerering
- De 2 første cifre repræsenterer fejlgrupperingen (50, …, 99)
- De sidste to cifre er en fortløbende tæller (00, 01, …, 99)
- Alle fejlkoder placeres i en specifik folder i hvert API
- En fejlkode oversættelse implementeres i sit eget VI
- En fejlkode-VI har et matchende ikon så de er genkendelige
- En fejlkode skal supportere multiple lingvistiske sprog
- Fejlkoder skal supportere at kunne kaldes med forskellige prioriteter uden sideeffekter
- Fejlkode VIs er private for APIet, men skal være genbrugelige internt hvor det giver mening
Der er med andre ord en masse overvejelser, som vi har gjort omkring fejlkodeoversættelse for os, og måske er alle eller nogle af dem brugbare for dig?
Ved at indkapsle oversættelsen i en VI, giver dette fordelen, at du kan bruge alle LabVIEWs søgeværktøjer til at finde, hvor den givne fejlkode bliver brugt. Oversættelsen af fejlkoder kan også genbruges, hvis de er funktionsmæssigt passer ind i en anden API funktion. Der er ingen grund til at oprette endnu en fejlkode til præcis den samme funktion i samme API.
En meget vigtig pointe er, at en VI til fejlkodeoversættelse er privat for det API, som implementerer den. Det fjerner muligheden for at genbruge den samme funktion på tværs af grænsefladen mellem to APIer. Når man tænker over det vil det skabe en mærkelig afhængighed. Så er det bedre at oprette VIen med det samme indhold, og dokumentere den i det andet API. Hvis det første API så fjerner fejlkoden, vil det andet API stadig virke. På samme måde gælder det, at udvikleren ikke skal synkronisere det fortløbende nummer for fejlkoden på tværs af API-erne. Der kan godt eksistere to fejlkoder med samme nummer i hvert sit API, så længe de eksisterer i hver deres bibliotek.
GPower Custom Error Assistant til at hjælpe udvikleren
Det kan være overvældende at skulle holde styr på alle disse elementer, når man udvikler kode, og derfor har vi hos GPower automatiseret selve oprettelsen af VIs til oversættelsen af fejlkoderne, så det kun er tilretningen af oversættelsen der mangler. Det sker via vores interne værktøj, GPower Custom Error Assistent.
Assistenten er bygget til at sikre konsistente løsninger på tværs af interne APIer samt kundeprojekter. Den sørger selv for at vælge det næste fortløbende nummer i rækken af fejlkoder inden for den kategori, ligesom den sørger for at gemme fejlkoden det rigtige sted. Derudover hjælper assistenten med at vise, hvilke fejl der hører til under den valgte kategori. Ved oprettelsen tager du stilling til, hvilken kategori af fejlkode du vil oprette, og navngiver fejlkoden.
Et resultat af en fejl 5500 kan ses på figur 4 nedenfor. Læg især mærke til, at nummeret for den enkelte fejloversættelse også bliver vist i ikonet for denne VI. Hvis fejlkoden kræver specifikke parametre til fejlsøgning, er det nemmere at ændre argumenterne, der allerede er oprettet og ellers slette dem. Derudover kan jeg lige kort nævne, at der i templaten også er indbygget support for sproglig oversættelse af fejlkoder.
Hvis vi kigger på et eksempel fra vores Application v2 pakke, hvor vi har funktionen ””, ses det let, hvordan fejlkoden implementeres, se billede 5.
De eventuelle fejl, som opstår inde i funktionen, oversættes alle til en fejl 5501 – ”VI Property Error” med en parameter til VIens placering på disken. Der kan med andre ord ikke komme andre fejlkoder ud fra denne funktion.
En afsluttende kommentar
Med denne artikel er du nu klædt godt på til at lave dine egne oversættelser af fejlkoder til specifikke fejlkoder. Jeg er godt med på, at du hverken har adgang til vores GPower Custom Error Assistent eller Application API, men disse skal mere ses som eksempler på, hvordan man KAN gøre. Det er ikke sikkert, at alle vores regler passer for dig, men vælg dem, som virker, og gør brug af dem. Det vigtigste er, at du er konsistent omkring det.
Her på falderebet vil jeg svare på det åbne spørgsmål, du måske sidder med. Måske du tænker, at det er mærkeligt, at der kun er plads til 100 fejlkoder i hver gruppe. Men hvis du har behov for 100 unikke fejlkoder uden genbrug inden for dit API, så er der andre problemer såsom modularisering af din kode at tage fat på.
Brug endelig kommentarsporet på LinkedIn, hvis du har feedback eller spørgsmål til artiklen.
Du skal KUN oversætte fejl på API grænsefladens funktioner.
– LabVIEW Champion, Jesper Kjær Sørensen, GPower
![Undgå at dine fejlkoder bliver den nye 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)
![Fejlhåndtering i LabVIEW [2:4]](https://gpower.io/wp-content/uploads/2026/06/Fejlhaantering-i-labview-jesper-kjaer-soerensen-gpower-300x169.webp)
![Fejlhåndtering i LabVIEW [2:4]](https://gpower.io/wp-content/uploads/2026/06/Fejlhaantering-i-labview-jesper-kjaer-soerensen-gpower.webp)