Fejlhåndtering

Den funktionsmåde, der er beskrevet i denne artikel, er kun tilgængelig, når funktionen til administration af fejl på formelniveau er slået til.

Power Fx understøtter fejlhåndtering på formelniveau. Denne funktion er som standard slået til for alle nye apps. Nogle ældre apps kan dog have slået den fra i Appindstillinger. Lad denne funktion være aktiveret.

1. Åbn lærredsappen i redigeringstilstand.
2. Gå til fanen Indstillinger for>opdateringer>, der er udgået .
3. Sørg for, at Deaktiver administration på formelniveau er deaktiveret.

Du kan få flere oplysninger under Styring af, hvilke funktioner der er aktiveret.

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 slutbrugeren, at der er sket noget uventet. De kan muligvis løse problemet selv med et andet input, eller de kan rapportere problemet til ejeren af appen.

Som appudvikler skal du tage kontrol over fejl i din app:

• Registrer og håndter en fejl. Hvis der er risiko for, at der opstår en fejl, skal du skrive appens formler 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. Hent fejlen ved hjælp af funktionerne IfError, IsError og IsErrorOrBlank i en formel.
• Rapportér en fejl. Hvis der ikke håndteres en fejl i formlen, hvor du stødte på den, bobler fejlen op til App.OnError-handleren . Du kan ikke erstatte fejlen, fordi den allerede er opstået og 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.
• Opret og genudløs en fejl. Endelig 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. Brug funktionen Error til at omstyrte en fejl, efter at den er blevet afhørt i IfError eller App.OnError.

Introduktion

Lad os starte med et simpelt eksempel.

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

1/Value( TextInput1.Text )

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

Det er klart, at du ikke ønsker, at en fejl skal hilse på brugeren, hver gang vedkommende starter denne app. "Text input" er sandsynligvis ikke den rette standard for tekstinputfeltet alligevel. Du kan løse problemet ved at ændre egenskaben Default for kontrolelementet TextInput til:

Blank()

Nu får du vist en anden fejl. Matematiske handlinger med tomme værdier, f.eks. division, gennemtvinger den tomme værdi til et nul. Denne værdi medfører en fejl ved division med nul. Hvis du vil løse dette problem, skal du beslutte, hvad den rette funktionsmåde er for denne situation i denne app. Svaret kan være at vise blank , når tekstinputtet er tomt. Du kan nå dette mål ved at ombryde formlen med funktionen IfError :

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

Nu erstattes fejlen med en gyldig værdi, og fejlbanneret forsvinder. Men du har måske taget fejl, IfError, som du brugte, dækker alle fejltyper, herunder indtastning af en forkert værdi, f.eks "hello". Du kan løse dette problem ved at justere IfError for kun at håndtere divisionen med nul og omstyrte alle andre fejl:

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

Så kør din app, og prøv 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 du skriver 4, får du det forventede resultat på 0,25:

Og hvis du skriver noget ulovligt, f.eks hello. , får du vist et fejlbanner:

Dette er et simpelt indledende eksempel. Du kan håndtere fejl på mange forskellige måder, afhængigt af appens behov:

1. I stedet for et fejlbanner kan du få vist "#Error" i etiketkontrolelementet med formlen. Hvis erstatningstyperne skal være kompatible med det første argument til IfError, skal du eksplicit konvertere det numeriske resultat til en tekststreng ved hjælp af funktionen Text .

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

   
2. I stedet for at ombryde denne specifikke forekomst med IfError kan du skrive en central App.OnError-handler . Du kan ikke erstatte den streng, der vises med "#Error", da fejlen allerede er opstået, og App.OnError kun leveres til at styre rapportering.

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

Fejloverførsel

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

Hvis celle A2 refererer til A1 med en formel, f.eks =A1*2. , overføres fejlen også via denne formel:

Fejlen erstatter den værdi, som formlen ellers ville beregne. Der er ingen resultat for multiplikationen i celle A2 – kun fejlen fra division i A1.

Power Fx fungerer på samme måde. Hvis du angiver en fejl som et argument til en funktion eller operator, udføres handlingen generelt ikke. Inputfejlen flyder igennem som resultatet af handlingen. For eksempel, Mid( Text( 1/0 ), 1, 1 ) returnerer en Division med Nul-fejl, da den inderste fejl passerer gennem Text-funktionen og Mid-funktionen:

Generelt passerer fejl ikke igennem kontrolelementers egenskaber i Power Apps. Lad os udvide det forrige eksempel med et andet kontrolelement, der vises, hvis den første etikets Text egenskab er en fejltilstand:

Det er fint, at fejl ikke overføres via et kontrolelement, fordi systemet overvåger fejl i inputtet til alle egenskaber for kontrolelementet. 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 muligvis ikke en fejl, selvom der overføres en til dem.

Observation af fejl

Power Fx registrerer ikke fejl, før formlen anvender fejlværdien.

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

Brug af funktionen Set med en fejl rapporterer ikke en fejl på det tidspunkt, hvor fejlen placeres i variablen. I Power Apps er der f.eks. en formel i App.OnStart, der placerer en division med nul-fejl i variablen x:

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

Du kan se fejl i en formel ved hjælp af funktionerne IfError, IsError og IsErrorOrBlank . Ved hjælp af 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 Power Fx har observeret en fejl, er det næste trin at rapportere fejlen til slutbrugeren.

I modsætning til Excel er der ikke altid et praktisk sted at vise et fejlresultat, da resultatet af en formel kan drive en egenskab, f.eks. X- og Y-koordinater for et kontrolelement, hvor der ikke er noget praktisk sted at vise noget 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 udføres, opstod fejlen allerede, og resultatet overføres 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. Denne kontekst indeholder oplysninger om typen af fejl, 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. Disse formler gør det muligt at udføre mere end én handling i en sekvens ved hjælp ; af kædeoperatoren (eller ;; afhængigt af landestandarden).

I dette tilfælde viser gitterkontrolelementet f.eks., hvad der er i tabellen T . 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:

Brug IfError 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, stopper resten af gentagelserne 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 er opstået (ved at undersøge AllErrors i IfError eller App.OnError).

Følgende formel resulterer f.eks. i, at ForAll returnerer to fejl (for divisionen med nul for Value 0, to gange) og Collection har tre poster (for hvornå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.

Appen rapporterer som standard den første fejl til slutbrugeren. I dette eksempel mislykkes begge Patch-kald , men det andet kald mislykkes med en division med nulfejl. Brugeren får kun vist den første fejl om indekset:

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

Non-adfærdsmæssige formler kan også returnere flere fejl. 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 du så tidligere, kan du gemme fejl i variabler. Du kan også inkludere fejl i datastrukturer, f.eks. tabeller. Denne fremgangsmåde er vigtig, fordi den sikrer, at en fejl i en post ikke kan gøre hele tabellen ugyldig.

Overvej f.eks. dette kontrolelement af typen datatabel i Power Apps:

Beregningen i AddColumns stødte 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 true.

Hvis der opstår en fejl under filtrering af en tabel, er hele posten en fejl. Handlingen returnerer stadig posten i resultatet, så slutbrugeren ved, at der var noget der, og at der er 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. Handlingen indeholder en fejlpost i stedet for originalen for at maksimere gennemsigtigheden for slutbrugerne og hjælpe med at foretage fejlfinding. I dette tilfælde returnerer IsError( Index( output, 2 ) ) sand.

Datakildefejl

De funktioner, der ændrer data i datakilder, såsom Patch, Collect, Remove, RemoveIf, Update, UpdateIf og SubmitForm, rapporterer fejl på to måder:

• Hver af disse funktioner returnerer en fejlværdi som resultat af handlingen. Du kan registrere fejl ved hjælp af IsError og erstatte eller undertrykke fejl ved hjælp af IfError og App.OnError som normalt.
• Efter handlingen returnerer funktionen Errors også fejlene for tidligere handlinger. Denne funktionsmåde kan være nyttig til visning af fejlmeddelelsen på en formularskærm uden at skulle registrere fejlen i en tilstandsvariabel.

Denne formel søger f.eks. efter en fejl fra Collect og viser 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.

Genudkastning af fejl

Nogle gange forventer du potentielle fejl og kan trygt ignorere dem. Hvis der registreres en fejl i IfError og App.OnError, som skal overføres til den næste højere handler, skal du ombryde den ved hjælp Error( AllErrors )af .

Oprettelse af dine egne fejl

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

Hvis du opretter dine egne fejl, skal du bruge værdier, der er større end 1.000, for at undgå potentielle konflikter med fremtidige systemfejlværdier.

ErrorKind-enum-værdier