Hibakezelés

Mindig is lesznek hibák. A hálózatok leállnak, a tárolók megtelnek, váratlan értékek érkeznek be. Fontos, hogy a logikája továbbra is megfelelően működjön a lehetséges problémák ellenére is.

A hibák a legtöbb esetben áthaladnak az alkalmazás képletein, majd az alkalmazás végfelhasználói jelentést kapnak erről. A végfelhasználó így tudja, hogy váratlan esemény történt, és így akár saját maga is kijavíthatja a problémát egy másik bemenet megadásával, vagy bejelentheti a problémát az alkalmazás tulajdonosának.

Alkalmazásfejlesztőként átveheti az irányítást az alkalmazásban előforduló hibák felett:

• Hibák észlelése és kezelése. Ha van rá esély, hogy hiba fordul elő, az alkalmazás képletei megírhatók úgy, hogy észleljék a hibafeltételeket, és újra megpróbálkozzanak a művelettel. A végfelhasználónak nem kell aggódnia amiatt, hogy hiba történt, mert a készítő figyelembe vette ennek a lehetőségét. Erre a célra az IfError, IsError és az IsErrorOrBlank függvények használhatók a képleteken belül.
• Hibák bejelentése. Ha a hibát nem oldja meg az a képlet, ahol az előfordult, a hibát továbbítja a rendszer az App.OnError kezelőnek. Itt a hibát a továbbiakban nem lehet lecserélni, mivel az már megtörtént, és a képlet számításainak részét képezi. Az App.OnError segítségével azonban szabályozhatja, hogy a rendszer miként jelentse a hibát a végfelhasználónak, és akár el is rejtheti a teljes hibajelentést. Az App.OnError egy közös fojtópontot is biztosít a hibajelentéshez a teljes alkalmazásban.
• Hibák létrehozása és újbóli kiváltása. Végső soron a saját logikáját felhasználva is észlelheti a hibafeltételt, egy olyan feltételt, amely alkalmazásspecifikus. Egyéni hibák létrehozásához használja a Hiba függvényt. A Hiba függvény akkor is használatos, amikor ismételten kiváltanak egy hibát, miután az lekérdezték az IfError vagy az App.OnError segítségével.

Első lépések

Kezdésként nézzünk meg egy egyszerű példát.

1. Új képernyő létrehozása a Power Apps vászonalapú alkalmazásban.
2. Szúrjon be egy TextInput vezérlőt. Alapértelmezés szerint a neve a következő lesz: TextInput1.
3. Címke vezérlő beszúrása.
4. Adja meg a Szöveg tulajdonságát a Címke vezérlőnek a képletben

1/Value( TextInput1.Text )

Hiba történt, mert egy TextInput vezérlő alapértelmezett szövege "Text input", amely nem alakítható át számmá. Alapértelmezés szerint ez nem gond: a végfelhasználó értesítést kap arról, hogy valami nem a várt módon működik az alkalmazásban.

Természetesen nem szeretnénk, hogy a felhasználó egy hibaüzenetet lásson minden alkalommal, amikor elindítja az alkalmazást. A "Text input" szövegbeviteli mező valószínűleg nem is a megfelelő választás alapértelmezés szerint. Ennek kijavításához módosítsa az Alapértelmezett tulajdonságot a TextInput vezérlő esetében a következőre:

Blank()

Most pedig egy másik hibával szembesülünk. Az üres értékkel rendelkező matematikai műveletek, például az osztás, az üres értéket nullára változtatják. Ez pedig ezzel nullával való osztási hibát okoz. Ennek megoldásához el kell döntenie, hogy mi a legmegfelelőbb viselkedés az alkalmazásban ehhez a helyzethez. A megoldás lehet az is, hogy üres értéket jelenítsen meg, amikor a szöveges bemenet üres. Ez úgy valósítható meg, ha beburkoljuk a képletet az IfError függvénnyel:

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

Most a hibát a rendszer egy érvényes értékre cseréli, és a hibát jelző címsáv eltűnik. Viszont az is lehet, hogy túllőttünk a célon, mivel az általunk használt IfError az összes hibára vonatkozóan érvényesül, beleértve azt is, ha hibás értéket írunk be, például a következőt: "hello". Ezt úgy oldhatjuk meg, ha az IfError beállítását úgy adjuk meg, hogy a nullával való osztást csak a hibák újbóli kiváltásával kezelje:

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

Futtassuk tehát az alkalmazást, és próbáljunk ki különböző értékeket.

Érték nélkül az alkalmazás indításakor nem jelenik meg válasz, mivel az alapértelmezett érték üres, ugyanakkor hiba sem jelenik meg, mivel az IfError helyettesíti a nullával való osztás jelentette hibát.

Ha beírjuk a 4-es számot, a várt 0,25-ös eredményt kapjuk:

Ha pedig illegális értéket írunk be (például hello), akkor a következő hibasáv jelenik meg:

Ez egy egyszerű bevezető példa. A hibakezelés az alkalmazás igényeitől függően sokféleképpen végrehajtható:

1. Hibasáv helyett megjeleníthettük volna a „#Hiba” értéket is a címkevezérlőben a képlettel együtt. Ahhoz, hogy a cserék típusa kompatibilis maradjon az IfError első argumentumával, a számbeli eredményt expliciten át kell alakítanunk szöveges sztringgé a Szöveg függvénnyel.

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

   
2. Ahelyett, hogy beburkoltuk az adott példányt az IfError használatával, írhattunk volna egy központosított App.OnError kezelőt. A „#Error” értékkel megjelenített sztring nem cserélhető le, mivel a hiba már megtörtént, és az App.OnError csak a jelentéskészítés szabályozása céljából van megadva.

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

Hibák propagálása

Mint ahogy az Excel esetében is, a hibák itt is áthaladnak a képleteken. Ha például az Excelben az A1 cellában az =1/0 képlet található, akkor az A1 cella a #DIV0! hibaértéket fogja megjeleníteni:

Ha az A2 cella az A1 cellára hivatkozik az =A1*2 képlettel, akkor a hiba arra a képletre is kihat:

A hiba lecseréli az egyébként kiszámított értéket. Az A2 cellában nincs eredménye a szorzásnak, csak az A1 cellában való osztásból származó hiba jelenik meg.

A Power Fx ugyanígy működik. Általában, ha egy függvény vagy operátor argumentumaként hibaüzenet jelenik meg, a műveletet a rendszer nem hatja végre, a bemeneti hiba pedig a művelet eredményeként végighalad a teljes elemen. Például a Mid( Text( 1/0 ), 1, 1 ) egy Nullával történő osztás hibát fog eredményezni, mivel a legbelső hiba kihat a Szöveg függvényre és a Mid függvényre:

Általában véve a hibák nem hatnak ki a Power Apps vezérlő tulajdonságaira. Egészítsük ki a korábbi példát egy további vezérlővel, amely akkor jelenik meg, ha az első címke Text tulajdonsága egy hibaállapot:

Nem gond, ha a hibák nem hatnak ki a teljes vezérlőre, mert a rendszer az összes vezérlőtulajdonság bemenetében figyeli a hibákat. A hiba nem tűnik el.

A legtöbb függvény és operátor a „hiba be, hiba ki” szabályt követi, de van néhány kivétel is. Az IsError, IsErrorOrBlank és IfError úgy vannak létrehozva, hogy hibákkal is működjenek, így elképzelhető, hogy akkor sem jelenítenek meg hibát, ha a rendszer átad egy hibát nekik.

A hibák nyomon követése

A hibákat csak akkor észleli a rendszer, ha felhasználja az értéküket.

Ennek következtében az If és a Select függvények néhány esetben nem jelenítenek meg hibát akkor sem, ha a rendszer átad nekik egyet. Vegyük a következő képletet: If( false, 1/0, 3 ). Ebben a képletben jelen van a nullával osztás hiba, de mivel az If nem tér ki arra az elágazásra a false érték miatt, a Power Fx és a Power Apps nem fog hibát jelenteni:

Ha a Set függvényt egy hibával használja, a rendszer nem fog hibát jelezni azon a ponton, ahol a hibát bevezették a változóba. Íme, a Power Apps egy olyan képlete az App.OnStart elemben, amely egy nullával való osztás hibát illeszt be a változóba x:

A rendszer nem jelez hibát, mert nem hivatkozik az x értékre. Amikor azonban hozzáadjuk a címkevezérlőt, és beállítjuk a Szöveg tulajdonságát x értékre, megjelenik a hiba:

A képleten belüli hibákat az IfError, az IsError és az IsErrorOrBlank függvényekkel követheti nyomon. Ezekkel a funkciókkal egy másik értéket is visszaadhat, másik műveletet is végrehajthat, vagy módosíthatja a hibát, mielőtt észlelnék és bejelentenék azt.

Hibák jelentése

Ha hibát észlel, a következő lépés a hiba végfelhasználónak való jelentése.

Az Exceltől eltérően nincs mindig könnyen elérhető hely a hiba eredményének megjelenítéséhez, mivel a képlet eredményeképpen olyan tulajdonság is megjelenhet, mint a vezérlőelem X és Y koordinátái, amelyek esetében nincs alkalmas hely bizonyos szöveg megjelenítésére. Az egyes Power Fx-állomások határozzák meg, hogy a rendszer hogyan jeleníti meg a hibákat a végfelhasználónak, valamint hogy milyen mértékű irányítása van a folyamat fölött a készítőnek. A Power Apps esetében megjelenik egy hibasáv, az App.OnError pedig azt irányítja, hogy miként jelenti a rendszer a hibát.

Fontos megjegyezni, hogy az App.OnError nem tudja lecserélni a hibát ugyanúgy, mint ahogy azt az IfError teszi. Az App.OnError végrehajtásakor a hiba már megtörtént, és az eredmény a többi képletre is kihatással van. Az App.OnError csak azt szabályozza, hogy a rendszer hogyan jelenti a hibát a végfelhasználónak, és egy horgot biztosít a készítő számára, hogy szükség esetén naplózza a hibát.

A FirstError és az AllErrors hatóköri változók környezeti információt biztosítanak a hibáról vagy hibákról. Ez tájékoztatást nyújt a hiba fajtájáról, a hiba származási helyéről és a hiba észlelési helyéről is.

Leállítás hibát követően

A viselkedésképletek támogatják a műveletek végrehajtását, az adatbázisok szerkesztését és az állapot módosítását. Ezek a képletek több művelet egymás utáni végrehajtását is lehetővé teszik a ; láncolási operátor használatával (vagy a ;; használatával, a területi beállítástól függően).

Ebben az esetben például a rácsvezérlő azt mutatja, hogy mi látható a T táblában. A gombok megnyomásával módosíthatjuk a táblában lévő állapotokat a két Patch-hívással:

Az összeláncolt viselkedési képletekben a műveletek nem állnak le az első hibát követően. Módosítsuk a példánkat úgy, hogy az első Patch-hívásban érvénytelen indexszámot adjon át. A második Patch a korábbi hiba ellenére is folytatódik. Az első hibát jelenti a rendszer a végfelhasználónak, és hibaként jeleníti azt meg a Studio rendszerében a vezérlőn:

Az IfError segítségével hiba után leállíthatja a végrehajtást. Az If függvényhez hasonlóan a függvény harmadik argumentuma olyan műveleteknek biztosít helyet, amelyeket a rendszernek csak akkor kell végrehajtania, ha nem merült fel hiba:

Ha a ForAll egyik ismétlése során hiba történik, a többi ismétlés nem áll le. A ForAll úgy lett kialakítva, hogy minden iterációt egymástól függetlenül hajtson végre, lehetővé téve a párhuzamos végrehajtást. Amikor befejeződött a ForAll művelet, a rendszer egy hibaüzenetet jelenít meg, amely tartalmazza az eddigi összes felmerült hibát (az AllErrors vizsgálatával az IfError vagy az App.OnError műveletekben).

Az alábbi képlet eredményeként például a ForAll két hibát ad vissza (a Value 0 értékének nullával való osztásáért, kétszer), a Collection pedig három rekorddal fog rendelkezni (ha a Value értéke nem 0): [1, 2, 3].

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

Több hiba kezelése

Mivel a viselkedésképlet egynél több műveletet is végrehajthat, egynél több hiba is bekövetkezhet.

Alapértelmezés szerint az első hibát a rendszer jelenti a végfelhasználónak. Ebben a példában mindkét Patch-hívás sikertelen lesz, a második nullával való osztás hiba miatt. Csak az első hiba (az indexszel kapcsolatos) jelenik meg a felhasználónak:

Az IfError függvény és az App.OnError hozzáférhet az AllErrors hatóköri változójával kapcsolatos összes hibához. Ebben az esetben ezt globális változóra állíthatjuk, és mindkét felmerült hibát megtekinthetjük. A táblában ugyanabban a sorrendben jelennek meg, amilyen sorrendben bekövetkeztek:

Nem viselkedésképletekben több hiba is visszaadható. Ha például a Patch függvényt egy kötegnyi rekorddal való frissítéshez használjuk, akkor több hiba is előfordulhat, egy-egy minden sikertelen rekord esetén.

Hibák a táblákban

Mint korábban láttuk, a hibák változókban is tárolhatók. A hibák adatstruktúrákban, például táblákban is tárolhatók. Ez azért fontos, hogy egy rekordban található hiba ne érvénytelenítse a teljes táblát.

Vegyük például a következő adattáblavezérlőt a Power Apps-ben:

Az AddColumns számítása során az értékek egyike esetén nullával való osztás hiba következett be. Az adott rekordnál a Kölcsönös oszlopnak hibaértéke van (nullával való osztás), a többi rekordban azonban nincs hiba és megfelelően működnek. IsError( Index( output, 2 ) ) hamis értéket ad vissza, és IsError( Index( output, 2 ).Value ) igaz értéket ad vissza.

Ha egy tábla szűrése során hiba történik, a teljes rekord hibának minősül, de ennek ellenére megjelenik az eredményben, hogy a végfelhasználó értesüljön a történtekről és a problémáról.

Vegyük a következő példát. Itt az eredeti táblában nincsenek hibák, de a szűrési művelet hibát hoz létre, valahányszor az Érték 0-val egyenlő:

A -5 és a -3 értékek szűrése megfelelően történik. A 0-s értékek hibát eredményeznek a szűrő feldolgozása során, ezért nem egyértelmű, hogy a rekordnak szerepelnie kell-e az eredményben vagy sem. A végfelhasználók által tapasztalt átláthatóság maximalizálása és a készítők által végrehajtott hibajavítások megkönnyítése érdekében egy hibarekordot helyeztünk el az eredeti rekord helyében. Ebben az esetben az IsError( Index( output, 2 ) ) kifejezés igaz értéket ad vissza.

Adatforrással kapcsolatos hibák

Az adatforrásokban található adatokat módosító függvények (például Patch, Collect, Remove, Removelf, Update, Updatelf és SubmitForm) kétféleképpen jelentik a hibákat:

• Ezen függvények mindegyike hibaértéket ad vissza a művelet eredményeként. A hibák az IsError használatával észlelhetők, illetve az IfError és az App.OnError használatával helyettesíthetők vagy visszavonhatók.
• A művelet után az Errors függvény visszaadja a korábbi műveletek hibáit is. A segítségével megjeleníthető egy hibaüzenet az űrlapképernyőn anélkül, hogy a hibát állapotváltozóban kellene rögzíteni.

Ez a képlet például a Collect függvényben keres hibát, és egyéni hibaüzenetet jelenít meg:

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

Az Errors függvény a futásidejű műveletek során előforduló korábbi hibákkal kapcsolatos információkat adja vissza. A segítségével megjeleníthető egy hiba az űrlapképernyőn anélkül, hogy a hibát állapotváltozóban kellene rögzíteni.

Hibák ismételt kiváltása

Időnként előfordulhatnak olyan potenciális hibák, amelyek biztonságosan figyelmen kívül hagyhatók. Az IfError és az App.OnError függvényeken belül, ha a rendszer olyan hibát észlel, amelyet továbbítani kell a következő magasabb szintű kezelőhöz, azt ismételten ki lehet váltani az Error( AllErrors ) függvénnyel.

Saját hibák létrehozása

Az Error függvénnyel saját hibákat is létrehozhat.

Ha saját hibákat hoz létre, ajánlott 1000 feletti értékeket használni a jövőbeli rendszerhibák értékeivel való ütközések elkerülése érdekében.

ErrorKind felsorolási értékek