Megosztás a következőn keresztül:

Kivételek és teljesítmény

Megjegyzés:

Ezt a tartalmat a Pearson Education, Inc. engedélyével nyomtatjuk újra a Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition című műből. Ezt a kiadást 2008-ban adták ki, és a könyvet azóta teljesen átdolgozták a harmadik kiadásban. Előfordulhat, hogy az oldalon található információk némelyike elavult.

A kivételekkel kapcsolatos gyakori probléma, hogy ha a rutinszerűen sikertelen kódhoz kivételeket használnak, a megvalósítás teljesítménye elfogadhatatlan lesz. Ez egy valós aggodalom. Ha egy tag kivételt vet ki, a teljesítménye nagyságrendekkel lassabb lehet. Azonban jó teljesítmény érhető el, miközben szigorúan betartja a hibakódok használatát tiltó kivételekre vonatkozó irányelveket. Erre két, ebben a szakaszban ismertetett minta utal.

❌ NE használjon hibakódokat olyan aggodalmak miatt, amelyek miatt a kivételek negatívan befolyásolhatják a teljesítményt.

A teljesítmény javítása érdekében használhatja a következő két szakaszban ismertetett Tester-Doer mintát vagy a Try-Parse mintát.

Tester-Doer minta

Néha a kivételdobó tag teljesítménye javítható úgy, hogy két részre bontjuk. Nézzük meg a Add felület ICollection<T> metódusát.

ICollection<int> numbers = ...
numbers.Add(1);

A metódus Add kivételt dob, ha a gyűjtemény csak olvasható. Ez teljesítményproblémát okozhat olyan helyzetekben, amikor a metódushívás várhatóan gyakran sikertelen lesz. A probléma megoldásának egyik módja annak tesztelése, hogy a gyűjtemény írható-e, mielőtt értéket próbálna hozzáadni.

ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
    numbers.Add(1);
}

A feltétel teszteléséhez használt tagot, amely a példánkban a tulajdonság IsReadOnly, tesztelőnek nevezzük. A tag, amely a példánkban a Add metódust — egy potenciálisan dobási műveletet — hajtja végre, doer-nek nevezzük.

✔️ VEGYE FIGYELEMBE a Tester-Doer mintát az olyan tagokhoz, amelyek gyakori helyzetekben kivételeket vethetnek ki, az olyan teljesítményproblémák elkerülése érdekében, amelyek a kivételekből adódnak.

Try-Parse minta

A rendkívül teljesítményérzékeny API-k esetében az előző szakaszban leírt Tester-Doer mintánál még gyorsabb mintát kell használni. A minta azt irányozza elő, hogy a tag neve módosításra kerüljön, így egy jól definiált teszteset a tag szemantikájának részévé válik. Például a DateTime egy Parse metódust definiál, amely kivételt dob, ha egy sztring elemzése sikertelen. Definiál egy megfelelő TryParse metódust is, amely megpróbál elemezni, de hamis értéket ad vissza, ha az elemzés sikertelen, és egy paraméterrel out visszaadja a sikeres elemzés eredményét.

public struct DateTime
{
    public static DateTime Parse(string dateTime)
    {
        ...
    }
    public static bool TryParse(string dateTime, out DateTime result)
    {
        ...
    }
}

Ha ezt a mintát használja, fontos, hogy szigorúan definiálja a kipróbálási funkciót. Ha a tag bármilyen más ok miatt meghibásodik, mint a pontosan meghatározott próbálkozás, a tagnak továbbra is generálnia kell egy megfelelő kivételt.

✔️ VEGYE FIGYELEMBE a Try-Parse olyan tagok mintáját, amelyek kivételeket vethetnek ki a gyakori forgatókönyvekben a kivételekkel kapcsolatos teljesítményproblémák elkerülése érdekében.

✔️ A DO a "Try" előtagot és a logikai visszatérési típust használja a mintát megvalósító metódusokhoz.

✔️ A Try-Parse minta szerint minden taghoz adj hozzá kivételdobó tagot.

© Részletek 2005, 2009 Microsoft Corporation. Minden jog fenntartva.

Újranyomva a Pearson Education, Inc. engedélyével, Krzysztof Cwalina és Brad Abrams Framework Design Guidelines: Konvenciók, Idiomák és Minták az Újrafelhasználható .NET Könyvtárak Számára, 2. kiadás című könyvéből, közzétéve 2008. október 22-én, a Addison-Wesley Professional által, a Microsoft Windows Fejlesztési Sorozat részeként.

Lásd még

  • Last updated on