Egyéni hibakezelés ASP.NET alkalmazásokban

Mellékelt példa megnyitása előtt szükséges egy WebCustomErrors nevű virtuális könyvtár létrehozása, mely a példa könyvtárára mutat. Ehhez nyissa meg a mellékelt mappa Tulajdonság ablakát és itt a Webmegosztás lapon engedélyezze a mappa megosztását olvasási és parancsfájlok futtatási jogával.

Ismert, hogy a strukturált hibakezelés szerves része a CLR-nek, ami az ASP.NET alkalmazásokra is kiterjed. Ha valamilyen hiba következik be az alkalmazásban fejlesztési-, vagy futási időben az ASP.NET egy alapértelmezett hibaoldal megjelenítésével jelzi azt. Ez nagyon hasznos a fejlesztőknek, mivel többnyire részletes információt közöl arról, hogy a hiba a kód melyik sorában következik be. A felhasználónak azonban nem szívesen küldenénk ki ilyen oldalakat, helyette egy saját készítésű lap jobban megfelel. Az ASP.NET alkalmazások Web.config állománya a megoldás, ahol a <customErrors> szegmensben beállítható az alkalmazás hibakezelő működése.

A <customErrors> konfigurációs szegmens jellemzői

A bejegyzés két attribútumot támogat és egy albejegyzést. A következő táblázat ezeket részletezi.

A <customErrors> által támogatott albejegyzésnek, mely az <errors> nevet viseli, lehet két attribútuma. Ez a bejegyzés többször előfordulhat és mindegyik egy-egy hiba kezelését adja meg.

Példák a beállításokra

Összefoglalva elmondható, hogy a Web.config fájl megfelelő bejegyzéseivel alapvetően 3-féle viselkedésre késztethető alkalmazásunk, attól függően, hogy a <customErrors> mode attribútumának milyen értéket adunk:

Ennél a beállításnál mind a lokális, mind a helyi kérések esetén az ASP.NET alapértelmezett hiba oldala jelenik meg. A konfigurációs fájlban az alábbi bejegyzést kell tenni:

<customErrors mode="Off">
</customErrors>

Ekkor mind a távoli, mind a lokális kérések esetén engedélyezett egy, az alapértelmezettől eltérő, saját hibaoldal megjelenítése. A defaultRedirect attribútumban meg kell adni ennek az oldalnak az URL-jét. Az ennek megfelelő bejegyzés a Web.config fájlban:

<customErrors mode="On" defaultRedirect=”/WebCustomErrors/MissingError.aspx”>
</customErrors>

Ekkor csak a távoli kérések esetén engedélyezett a saját weblap megjelenítése hiba esetén. Helyi kérés esetén a fent bemutatott, nem túl barátságos oldalt kapjuk. A bejegyzés pedig:

<customErrors mode="RemoteOnly" defaultRedirect=”/WebCustomErrors/MissingError.aspx”>
</customErrors>

A <customErrors> tag albejegyzése segítségével finomíthatunk a hibakezelés módján. Felhasználható arra, hogy a meghatározott kódszámú hiba bekövetkezésekor milyen oldalra navigálja a felhasználót.

A példaprogramban két hibakód kezelésére tartalmaz értékeket a <customErrors> tag. A „404”-es kódszámú hiba akkor következik be, amikor nem létező erőforrást, lapot kér a kliens, az „500”-as pedig, amikor valamilyen szerverhiba következik be. A bejegyzések:

<customErrors mode="On">
  <error statusCode="404" redirect="/WebCustomErrors/MissingError.aspx" />
  <error statusCode="500" redirect="/WebCustomErrors/IISError.aspx" />
</customErrors>

A beállítás eredményeképpen a megfelelő, előre elkészített oldalak jelennek meg a kliens oldalon a szabványos hibaoldalak helyett.

A hibaoldal megjelenésekor, attól függően, hogy milyen http metódust használunk a kérés elküldésére látható, hogy a hibakezelő oldal valamilyen paramétert kap. A paraméter egy előredefiniált paraméter-neve aspxerrorpath-, mely megadja, hogy milyen erőforrás kérésekor keletkezett a hiba.

A weboldalak között átadott paramétereket, így az aspxerrorpath paramétert is kiolvashatjuk a System.Collections.Specialized névtér NameValueCollection osztályának segítségével. Az osztályt példányosítva a keletkezett objektum voltaképpen egy tömb, ahol az elemek a lapok között átadott paraméterek értékei, melyekre a paraméter nevével is hivatkozhatunk. Látható a kódban, hogy a tömb elemei a HttpRequest osztály Request nevű, a http kérést reprezentáló objektumának QueryString property-jének elemei.

Label3.Text = Request.QueryString["aspxerrorpath"];