Fejlhåndtering

Bemærk!

Den funktionsmåde, der beskrives i denne artikel, er kun tilgængelig, når prøveversionsfunktionen Fejlstyring på formelniveau i Indstillinger>Kommende funktioner>Forhåndsversion er slået til. Få flere oplysninger her: Styre, hvilke funktioner der aktiveres

Fejl opstår. Netværk går ned, lagerplads bliver fyldt op, uventede værdier strømmer ind. Det er vigtigt, at din logik fortsat fungerer korrekt i forhold til potentielle problemer.

Fejl strømmer som standard gennem formlerne i en app og rapporteres til slutbrugeren af appen. På denne måde ved slutbrugerne, at der er sket noget uventet. De kan muligvis selv løse problemet med et andet input, eller de kan rapportere problemet til ejeren af appen.

Som appudvikler kan du styre fejl i din app:

• Registrering og håndtering af en fejl. Hvis der er risiko for, at der opstår en fejl, kan appens formler skrives for at registrere fejlbetingelsen og prøve at udføre handlingen igen. Slutbrugeren behøver ikke at være bekymret for, om der er opstået en fejl, fordi udvikleren har taget højde for muligheden. Det sker ved hjælp af funktionerne IfError, IsError og IsErrorOrBlank i en formel.
• Rapportering af en fejl. Hvis en fejl ikke håndteres i den formel, hvor den blev fundet, vises fejlen til i App.OnError-handleren. Her kan fejlen ikke længere erstattes, da den allerede er opstået, og den er en del af formelberegninger. Men du kan bruge App.OnError til at styre, hvordan fejlen skal rapporteres til slutbrugeren, herunder hvordan du helt undertrykker fejlrapportering. App.OnError giver også et fælles flaskehalspunkt for fejlrapportering på tværs af hele appen.
• Oprettelse og genudløsning af en fejl. Til sidst kan du registrere en fejlbetingelse med din egen logik, en betingelse, der er specifik for din app. Brug funktionen Error til at oprette brugerdefinerede fejl. Funktionen Error bruges også til at udløse en fejl igen, når den er blevet undersøgt i IfError eller App.OnLike.

Introduktion

Lad os starte med et simpelt eksempel.

1. Opret et nyt skærmbillede i en Power Apps-lærredapp.
2. Indsæt et TextInput-kontrolelement. Navnet TextInput1 angives som standard.
3. Indsæt et Label-kontrolelement.
4. Angiv egenskaben Text for kontrolelementet Label til formlen

1/Value( TextInput1.Text )

Der opstår en fejl, fordi standardteksten i et TextInput-kontrolelement er "Text input", som ikke kan konverteres til et tal. Det er som standard en god ting: Slutbrugeren får en meddelelse om, at noget ikke fungerer som forventet i appen.

Vi ønsker naturligvis ikke, at brugerne får en fejl, hver gang de starter denne app. "Text input" er sandsynligvis ikke den rette standard for tekstinputfeltet alligevel. Det kan du løse ved at ændre egenskaben Standard for kontrolelementet TextInput til:

Blank()

Men nu opstår der en anden fejl. Matematiske handlinger med tom, f.eks. division, tvinger den tomme værdi til et nul. Og det medfører nu en division med nul-fejl. For at afhjælpe dette skal vi beslutte, hvad den rette funktionsmåde i appen skal være i denne situation. Svaret kan være at vise tom, når tekstinputtet er tomt. Det kan vi gøre ved at bruge formlen med funktionen IfError:

IfError( 1/Value( TextInput1.Text ), Blank() )

Nu erstattes fejlen med en gyldig værdi, og fejlbanneret er væk. Men vi har måske skudt over målet. IfError, som vi har brugt, dækker alle fejl, herunder indtastning af en ugyldig værdi, f.eks. "hello". Vi kan løse dette ved at finjustere IfError til at håndtere tilfældet med division med nul og udløse alle andre fejl igen:

IfError( 1/Value( TextInput1.Text ), 
         If( FirstError.Kind = ErrorKind.Div0, Blank(), Error( FirstError ) ) )

Så lad os køre vores app og prøve nogle forskellige værdier.

Som når appen starter, vises der intet svar, hvis der ikke er angivet en værdi, da standardværdien er tom, men der vises heller ingen fejl, da IfError erstatter division med nul-fejlen.

Hvis vi skriver 4, får vi det forventede resultat 0,25:

Og hvis vi skriver en ugyldig værdi, f.eks. hello, modtager vi et fejlbanner:

Dette er et simpelt indledende eksempel. Fejlhåndtering kan udføres på mange forskellige måder, afhængigt af appens behov:

1. I stedet for et fejlbanner kunne vi have vist "#Error" i etiketkontrolelementet med formlen. Hvis du vil sikre, at typerne af erstatningerne er kompatible med det første argument til IfError, skal du eksplicit konvertere det numeriske resultat til en tekststreng med funktionen Text.

   IfError( Text( 1/Value( TextInput1.Text ) ), 
            If( FirstError.Kind = ErrorKind.Div0, Blank(), "#Error" )
   

   
2. I stedet for at bruge denne specifikke forekomst med IfError kunne vi have skrevet en central App.OnError-handler. Vi kan ikke erstatte den streng, der vises, med "#Error", da fejlen allerede er opstået, og App.OnError kun angives for at styre rapportering.

   If( FirstError.Kind <> ErrorKind.Div0, Error( FirstError ) )
   

Fejloverførsel

Fejl flyder gennem formler stort på samme måde som i Excel. Hvis celle A1 i Excel f.eks. har formlen =1/0, vises fejlværdien #DIV0! i A1:

Hvis celle A2 refererer til A1 med en formel som f.eks. =A1*2, overføres fejlen også via den pågældende formel:

Fejlen erstatter den værdi, der ellers ville være blevet beregnet. Der er ingen resultat for multiplikationen i celle A2 – kun fejlen fra division i A1.

Power Fx fungerer på samme måde. Hvis der angives en fejl som argument for en funktion eller operator, sker handlingen som regel ikke, og inputfejlen vil flyder igennem som følge af handlingen. Mid( Text( 1/0 ), 1, 1 ) returnerer f.eks. en division med nul-fejl, da den inderste fejl passerer gennem funktionen Text og funktionen Mid:

Fejl strømmer generelt ikke gennem egenskaber for Power Apps-kontrolelementer. Lad os udvide det forrige eksempel med et ekstra kontrolelement, der vises, hvis egenskaben Text for den første etiket er i fejltilstand:

Det er ok, at fejl ikke overføres via et kontrolelement, da systemet observerer fejl i inputtet i alle egenskaber for kontrolelementer. Fejlen går ikke tabt.

De fleste funktioner og operatorer følger reglen "fejl ind, fejl ud", men der er visse undtagelser. Funktionerne IsError, IsErrorOrBlank og IfError er designet til at arbejde med fejl, så de returnerer måske ikke en fejl, selvom der overføres en til dem.

Observation af fejl

Fejl observeres først, når deres værdi bruges.

Derfor returnerer funktionerne If og Select måske heller ikke en fejl, hvis der overføres en. Overvej formlen If( false, 1/0, 3 ). Der er en division med nul-fejl i denne formel, men da If ikke indtager forgreningen på grund af false, rapporterer Power Fx og Power Apps ikke en fejl:

Hvis du bruger funktionen Set med en fejl, rapporteres der ikke en fejl på det sted, hvor fejlen placeres i variablen. I Power Apps er der f.eks. her en formel App.OnStart, der anbringer en division med nul-fejl i variablen x:

Der rapporteres ingen fejl, da der ikke refereres til x. Men i det øjeblik, vi tilføjer et etiketkontrolelement og angiver egenskaben Text til x, vises fejlen:

Du kan observere fejl i en formel med funktionerne IfError, IsError og IsErrorOrBlank. Med disse funktioner kan du returnere en alternativ værdi, udføre en alternativ handling eller ændre fejlen, før den observeres og rapporteres.

Rapportering af fejl

Når en fejl er observeret, skal du som det næste rapportere fejlen til slutbrugeren.

I modsætning til Excel er der ikke altid et praktisk sted at få vist et fejlresultat, da en formel kan medføre en egenskab, f.eks. X- og Y-koordinater for et kontrolelement, som der ikke er et praktisk sted at få vist tekst for. Hver Power Fx-vært styrer, hvordan fejl i sidste ende vises for slutbrugeren, og hvor meget kontrol udvikleren har over denne proces. I Power Apps vises der et fejlbanner, og App.OnError bruges til at styre, hvordan fejlen rapporteres.

Det er vigtigt at være opmærksom på, at App.OnError ikke kan erstatte fejlen på samme måde som IfError. På det tidspunkt, hvor App.OnError køres, er fejlen allerede sket, og resultatet er overført via andre formler. App.OnError styrer kun, hvordan fejlen rapporteres til slutbrugeren, og giver udvikleren en krog til at logge fejlen, hvis det ønskes.

Omfangsvariablerne FirstError og AllErrors giver kontekstafhængige oplysninger om den eller de fejl, der er opstået. Her kan du se, hvilken type fejl der opstod, hvor fejlen opstod, og hvor den blev observeret.

Stopper efter en fejl

Formler for funktionsmåde understøtter udførelse af handling, redigering af databaser og ændring af tilstand. Med disse formler kan der udføres mere end én handling i rækkefølge ved hjælp af sammenkædningsoperatoren ; (eller ;; afhængigt af landestandard).

I dette tilfælde viser gitterkontrolelementet f.eks., hvad der findes i T-tabellen. Hver gang der vælges en knap, ændres tilstanden i denne tabel med to Patch-kald:

I en sammenkædet formel for funktionsmåde stopper handlinger ikke efter den første fejl. Lad os ændre vores eksempel, så det sender et ugyldigt indeksnummer under det første Patch-kald. Den anden Patch fortsætter på trods af denne tidligere fejl. Den første fejl rapporteres til slutbrugeren og vises som en fejl i Studio i kontrolelementet:

IfError kan bruges til at stoppe udførelsen efter en fejl. På samme måde som med funktionen If giver det tredje argument for denne funktion mulighed for at anbringe handlinger, der kun skal udføres, hvis der ikke opstår en fejl:

Hvis der opstår en fejl under en af gentagelserne af ForAll, standser de øvrige gentagne udførelser ikke. ForAll er designet til at udføre hver iteration uafhængigt, hvilket giver mulighed for parallel udførelse. Når ForAll er fuldført, returneres der en fejl, som indeholder alle de fejl, der opstår (ved at undersøge AllErrors i IfError eller App.OnError).

Følgende formel vil f.eks. resultere i, at ForAll returnerer to fejl (for divisionen med nul for Value 0 eller to gange), og Collection vil have tre poster (for når Value ikke er 0): [1, 2, 3].

Clear( Collection ); 
ForAll( [1,0,2,0,3], If( 1/Value > 0, Collect( Collection, Value ) ) );

Arbejde med flere fejl

Da en formel for funktionsmåde kan udføre mere end én handling, kan den også støde på mere end én fejl.

Den første fejl rapporteres som standard til slutbrugeren. I dette eksempel mislykkes begge Patch-kald – den anden med en division med nul-fejl. Det er kun den første fejl (om indeks), der vises til brugeren:

Funktionen IfError og App.OnError kan få adgang til alle de fejl, der opstår i forbindelse med omfangsvariablen AllErrors. I dette tilfælde kan vi angive denne til en global variabel og se på begge de fejl, der er opstået. De vises i tabellen i samme rækkefølge, som de opstod:

Flere fejl kan også returneres i formler uden funktionsmåde. Hvis du f.eks. bruger funktionen Patch sammen med en postbatch, der skal opdateres, returneres der muligvis flere fejl, én for hver post, der mislykkes.

Fejl i tabeller'

Som vi så tidligere, kan fejl gemmes i variabler. Fejl kan også inkluderes i datastrukturer, f.eks. tabeller. Dette er vigtigt, så en fejl i én post ikke kan gøre hele tabellen ugyldig.

Du kan f.eks. overveje dette kontrolelement af typen datatabel i Power Apps:

Beregningen i AddColumns er stødt på en division med nul-fejl for en af værdierne. For den pågældende post indeholder kolonnen Reciprocal en fejlværdi (division med nul), men de andre poster har ingen fejl og er, som de skal være. IsError( Index( output, 2 ) ) returnerer falsk og IsError( Index( output, 2 ).Value ) returnerer sand.

Hvis der opstår en fejl under filtrering af en tabel, er hele posten en fejl, men den returneres stadig i resultatet, så slutbrugeren ved, at der var noget i vejen, og at der opstod et problem.

Brug dette eksempel. Her indeholder den oprindelige tabel ingen fejl, men filtreringshandlingen opretter en fejl, hver gang Value er lig med 0:

Værdierne -5 og -3 filtreres korrekt ud. Værdierne 0 resulterer i en fejl under behandling af filteret, og derfor er det uklart, om posten skal medtages i resultatet eller ej. Hvis du vil maksimere gennemsigtighed for slutbrugere og hjælpe udviklere med at foretage fejlfinding, skal du inkludere en fejlpost i stedet for originalen. I dette tilfælde returnerer IsError( Index( output, 2 ) ) sand.

Datakildefejl

De funktioner, der ændrer dataene i datakilder som f.eks. rapportfejl af typerne Patch, Collect, Remove, RemoveIf, Update, UpdateIf og SubmitForm på to måder:

• Hver af disse funktioner returnerer en fejlværdi som resultat af handlingen. Der kan registreres fejl ved hjælp af IsError, og de kan erstattes eller undertrykkes med IfError og App.OnError som normalt.
• Efter handlingen returnerer funktionen Fejl også fejlene for tidligere handlinger. Det kan være praktisk, hvis du vil have vist fejlmeddelelsen på et formularskærmbillede, uden at du behøver at registrere fejlen i en tilstandsvariabel.

Denne formel kontrollerer f.eks., om der er fejl i Collect, og der vises en brugerdefineret fejlmeddelelse:

IfError( Collect( Names, { Name: "duplicate" } ),
         Notify( $"OOPS: { FirstError.Message }", NotificationType.Warning ) )

Funktionen Errors returnerer også oplysninger om tidligere fejl under kørselshandlinger. Det kan være praktisk, hvis du vil have vist en fejlmeddelelse på et formularskærmbillede, uden at du behøver at registrere fejlen i en tilstandsvariabel.

Fejl, der udløses igen

Undertiden forventes der visse mulige fejl, som uden problemer kan ignoreres. Hvis der registreres en fejl i IfError og App.OnError, som skal overføres til handleren på næste niveau, kan den udløses igen med Error( AllErrors ).

Oprettelse af dine egne fejl

Du kan også oprette dine egne fejl ved hjælp af funktionen Error.

Hvis du opretter dine egne fejl, anbefales det, at du bruger værdier over 1000 for at undgå potentielle konflikter med fremtidige værdier for systemfejl.

ErrorKind-optællingsværdier

ErrorKind-optælling	Værdi	Beskrivelse
AnalysisError	18	Systemfejl. Der opstod et problem med kompileringsanalyse.
BadLanguageCode	14	Der blev brugt en ugyldig eller ikke-genkendt sprogkode.
BadRegex	15	Ugyldigt regulært udtryk. Kontrollér den syntaks, der bruges sammen med funktionerne IsMatch, Match eller MatchAll.
Conflict	6	Den post, der opdateres, er allerede ændret ved kilden, og konflikten skal løses. En standardløsning er at gemme eventuelle lokale ændringer, opdatere posten og anvende ændringerne igen.
ConstraintViolated	8	Posten kunne ikke bestå en begrænsningskontrol på serveren.
CreatePermission	3	Brugeren har ikke tilladelse til at oprette en post for datakilden. Funktionen Collect blev f.eks. kaldt.
DeletePermissions	5	Brugeren har ikke tilladelse til at slette en post for datakilden. Funktionen Remove blev f.eks. kaldt.
Div0	13	Division med nul.
EditPermissions	4	Brugeren har ikke tilladelse til at oprette en post for datakilden. Funktionen Patch blev f.eks. kaldt.
GeneratedValue	9	En værdi er ved en fejl blevet overført til serveren for et felt, der automatisk beregnes af serveren.
InvalidFunctionUsage	16	Ugyldig brug af en funktion. Et eller flere af argumenterne til funktionen er ofte forkerte eller bruges på en ugyldig måde.
FileNotFound	17	SaveData-lageret blev ikke fundet.
InsufficientMemory	21	Der er ikke hukommelse eller lager nok på enheden til handlingen.
InvalidArgument	25	Et ugyldigt argument blev overført til en funktion.
Internal	26	Systemfejl. Der opstod et internt problem med en af funktionerne.
MissingRequired	2	Der mangler et påkrævet felt for en post.
Network	23	Der opstod et problem med netværkskommunikation.
None	0	Systemfejl. Der er ingen fejl.
NotApplicable	27	Der er ingen tilgængelig værdi. Det er praktisk, når der skal skelnes mellem en tom værdi, som kan behandles som et nul i numeriske beregninger, og tomme værdier, der skal markeres som et potentielt problem, hvis værdien bruges.
NotFound	7	Posten blev ikke fundet. Det kan f.eks. være den post, der skal ændres i funktionen Patch.
NotSupported	20	Handlingen understøttes ikke af denne afspiller eller enhed.
Numeric	24	En numerisk funktion blev brugt på en forkert måde. For eksempel Sqrt med -1.
QuotaExceeded	22	Lagerkvote er overskredet.
ReadOnlyValue	10	Kolonnen er skrivebeskyttet og kan ikke ændres.
ReadPermission	19	Brugeren har ikke tilladelse til at læse en post for datakilden.
Sync	1	Datakilden rapporterede en fejl. Se flere oplysninger i kolonnen Message.
Unknown	12	Der opstod en fejl, men af en ukendt type.
Validation	11	Posten bestod ikke en valideringskontrol.