Fejlhåndtering i LabVIEW [2:4]

Dette indlæg [2: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...?

”Det virkede altså på min maskine!” Det er mantraet for alle programmører, der ikke mestrer fejlhåndtering. Det er selvfølgelig ikke noget, DU siger 😊. Men måske har du en kollega, som siger det, og så kan du jo eventuelt sende denne artikel til ham, efter du har læst den.

Som jeg nævnte i min sidste artikel, er det vigtigt, at du identificerer, hvilke fejl som kan opstå i din kode. I denne artikel får du tips og tricks til:

Håndtering af alle fejl fra en funktion

Fejlhåndtering en fundamental del af programmering. Hvis du som udvikleren vælger at undertrykke fejlene fra en funktion, er det vigtigt, at du kommunikerer det videre til den næste, som skal håndtere koden. Dette kunne være dig selv om seks måneder.

Det har vi hos GPower løst ved at lave vores eget bibliotek til at håndtere og forbedre netop denne kommunikation. Jeg vil spare dig for at gå i detaljer med alle vores nye funktioner, men blot fremhæve, hvad vi gør, når vi specifikt undertrykker fejlene fra en funktion i koden.

1: Ignore Error: Når du vil ignorere en fejl

Vores ”Ignore Error” funktion er lavet for at vise, at programmøren har besluttet, at fejl fra denne funktion bliver ignoreret. Det virker måske fjollet for en inkarneret softwareudvikler som dig selv, og du tænker måske, at man jo bare kan lade være med at forbinde error wiren fra den her funktion til noget, så har man det samme resultat.

Det er delvist rigtigt, men dette kommunikerer direkte til læseren, at det er en bevidst handling. Derudover er en fordel også, at man kan bruge standard LabVIEW søgefunktioner til at søge efter alle de steder, hvor fejl bevidst bliver ignoreret. Ligeledes sender “Ignore Error” et visuelt praj til læseren om, at disse fejl bliver ignoreret med vilje, og ikke bare fordi udvikleren havde travlt og glemte at forbinde dem. En anden fordel er også, at hvis man bruger VI Analyzer, kan det bruges til at undertrykke advarsler om fejl, som ikke bliver håndteret (Billede 1).

Der er forskel på, om man forsøger at undertrykke alle fejlene fra en funktion, eller om man fokuserer på den enkelte fejl med en given fejlkode. Her er det, at man skal være varsom som udvikler: Den funktion man udvikler, kan kun holdes til ansvar for de fejlkoder, som den kan generere. Derfor er det vigtigt, at man ikke fjerner en eventuel fejl, som man har modtaget som input via ”Error In” kontrollen. I eksemplet nedenfor på billede 2 ses, at det kun er fejlen fra valideringsfunktionen, som bliver fjernet, hvorimod alle andre udefrakommende fejl med koden 9 bliver rapporteret videre (Billede 2).

2: Gentagelse af den fejlende handling

Nogle gange kan det være praktisk at gentage det, som fejler. Eksempelvis når du har med hardware eller netværk at gøre. Der kan være sket noget ude i “virkeligheden”, som koden ikke kender til. Det kan være, at netværket er blevet genstartet af IT, eller at serveren er optaget af at håndtere en anden forespørgsel. I tilfælde som disse kan det være en god idé at indbygge en strategi omkring gentagelse, og det er nemt i LabVIEW! Her er to eksempler på strategier:

Eksemplet ovenfor (Billede 3) forsøger at skabe netværksforbindelse og prøver at skabe forbindelsen, så længe det fejler. Som udvikler skal man så også være opmærksom på at indbygge en håndtering af programmets nedlukning, evt. ved at fjerne fejlene under nedlukning. Således at programmet kan lukke ned, hvis brugeren ønsker det. Dette kan man afhjælpe med den anden strategi: At have et begrænset antal forsøg til at forbinde, som vises på billedet nedenfor (Billede 4):

Ved at begrænse antallet af forsøg vil programmet kunne forsøge at forbinde tre gange for derefter at afvente interaktion fra brugeren. Det kan være et mere brugervenligt scenarie, hvor brugeren så bedes starte operationen igen til at tage tre nye forsøg.

Bemærk her, at der i begge strategier bevidst ikke er brugt skifteregistre til at gemme fejlen fra den forrige kørsel, da det vil ødelægge hele funktionaliteten af gentagelsesfunktionen. Derudover er der her brugt en casestruktur til at skærme for udefrakommende fejl, som også ville ødelægge gentagelsesfunktionen. Der findes mange flere metoder til at implementere en gentagelsesfunktion her.

3: Programmeringsteknikker til fejlhåndtering

I eksemplet med gentagelse af den fejlende proces brugte jeg en casestruktur til at skærme mod udefrakommende fejl. Det gav mening i netop dette eksempel, men i de fleste LabVIEW-primitiver og funktioner anvendes det, som på engelsk kaldes ”Standard Error Behavior”. Dette kan groft oversættes til normal fejlopførsel. Som eksempel: Hvis der er en udefrakommende fejl på error wiren ind i en funktion, eller primitiv udfører denne ikke sin handling, men lader bare fejlen passere igennem. Dette kan ses som den generelle opførsel i tilfælde af fejl.

Mange LabVIEW-udviklere implementerer en casestruktur i alle deres VIs, som det kan ses på billede 5 i det venstre diagram ovenfor. Denne metode kan ikke anbefales, da man forhindrer compileren i at optimere koden. Koden skal køre 99.9% af sin levetid i den tilstand, hvor der ikke er en fejl, og er bygget af funktioner som i forvejen implementerer den ønskede opførsel.

Derfor bør du lave koden som i diagrammet ovenfor til højre. Retteligt skal det siges, at der også er nogle funktioner og primitiver, som udfører deres funktion på trods af fejl, f.eks. ”Close Reference”-funktionen. For disse er error wiren brugt til at synkronisere, hvornår funktionen udføres. Det står oftest i dokumentationen for den enkelte funktion, hvordan den opfører sig ved fejl.

4: Undgå at bruge Warnings - det er bare støj

Det næste eksempel, jeg vil belyse, er fra NI Modbus TCP driveren, hvor næsten alle fejl bliver nedgraderet til at være advarsler. Nedgraderingen sker for at sikre, at det er meget få fejl, som kan stoppe driveren fra at fortsætte sin kørsel. På billede 6 har jeg modificeret koden, så man kan se alle tilstande af casestrukturen samtidig.

På billede 6 ovenfor ses, at casestrukturen kun lader de fejlnumre passere, som opstår, når forbindelsen ikke kan vedligeholdes, mens alle andre fejlnumre bliver nedgraderet til at være en advarsel. Da denne VI indgår i en state-machine, som stopper, hvis der opstår en fejl, har programmøren vurderet, at det var en nødvendighed at nedgradere alle andre fejl.

Sideeffekten er bare, at alle advarsler uden filtrering bliver rapporteret til brugeren grundet brugen af ”Connection Reference”. Det er dermed op til brugeren at håndtere disse selv. Det kunne f.eks. være, at der går for lang tid inden TCP-klienten skriver til TCP- serveren, og derfor responderer driveren med en fejl 56 “Connection Timeout”, som bliver nedgraderet til en advarsel 56 “Connection Timeout”. På denne måde er det op til ham eller hende, der implementerer brugen af driveren at håndtere, om det har nogen indflydelse for den givne applikation.

En afsluttende kommentar

Denne artikel er kommet omkring mange emner inden for fejlhåndtering, og jeg håber, at du er blevet inspireret til at bruge noget af det i dit eget arbejde. Tanken bag artiklen er netop at afmystificere fejlhåndtering. At gøre det nemmere at identificere, hvad man kan, og hvad man, efter min mening, bør gøre under udviklingsprocessen. Der er ikke faste regler inden for fejlhåndtering, men de beskrevne værktøjer og teknikker har helt sikkert været guld værd for mig.

Den næste artikel kommer til at handle om GPowers koncept om Custom Errors, og hvorfor vi synes, det er en god idé.

Hvis du vil beholde din nattesøvn og spare penge, er det bare med at komme i gang med fejlhåndtering.

– LabVIEW Champion, Jesper Kjær Sørensen, GPower

Om GPower

Hos GPower leverer vi robuste og skalerbare løsninger på tværs af industrier fra forskning til produktion. Vores modulære software hjælper jer med at optimere og effektivisere, så I kan fokusere på jeres kerneforretning.