kivétel kezelése

szavazat
2

Strukturálni kivételkezelés rossz? Mi a helyes megoldás kivételek?

EDIT: Kivétel kezelése .NET C #.

Én általában egy sor speciális kivétel osztályok (DivideByZeroException, ArrayTypeMismatchException) és nincs egy általános „catch (Exception ex)”.

A gondolkodás mögött az, hogy elvárom bizonyos kivételek előfordulnak, és konkrét intézkedések meghatározása, amikor azok megtörténnek, és a váratlan kivételek nőne ki a felületen (Windows vagy web). Ez egy jó gyakorlat?

A kérdést 09/12/2008 15:31
a forrás felhasználó
Más nyelveken...                            


5 válasz

szavazat
6

Nem tudom, hogy mit jelent a „strukturált kivételkezelés.”

A legrosszabb dolog, ami történhet kivételkezelés, hogy „lenyelni” az eltéréssel, vagy kezelni csendben.

Ne tedd ezt:

try {
   ...
}
catch (Exception e) {
   //TODO: handle this later
}

Ez nagyon gyakran történik lustaságból kap kódot összeállításához. Ha nem tudja, hogyan kell kezelni a kivételt, egy adott szinten, van módszer dobja a kivételt, és legalább egy fogás minden felvezető a tetején. Visszajelzést adjon valahogy (a GUI, oldal / e-mail egy támogató személy, log file), hogy a probléma végül kap rögzített. Csendben fogása kivételt szinte mindig vezet a nagyobb probléma történik a későbbiekben, és ez is nehéz nyomon követni.

Válaszolt 09/12/2008 15:39
a forrás felhasználó

szavazat
3

Catch nyilatkozatok + Veremkövetések. Soha ne elkapni kivétel nélkül nyomtat veremkövetést, akkor vagy valaki más lesz a pénztár, hogy a kódot és helye veremkövetések a Catch blokk, ha hiba történik, és a naplófájlok, vagy üres homályos.

Válaszolt 09/12/2008 15:33
a forrás felhasználó

szavazat
1

Ez egy összetett téma ... vannak könyvek ... de ... Két fő típusa a kivételkezelés ... inline, ahol a kódot kell találni a lehetséges hibák inline a kódot, amely egy eljárás vagy rutin „normális esetben” végre, és strukturált kivételkezelés, ahol a kód máshol, és teh infrastruktúra úgy tervezték, hogy automatikusan switych e kivételkezelés kódot, amikor váratlan esemény (hiba) történik ... Mindkettő advantedges és hátrányok. Az „inline” megközelítés hajlamos termelni kód, amely sokkal inkább zsúfolt (hibakóddal), és nehezebb olvasni és karbantartani. De ez könnyebb előállítani elöl, mivel nem igényel semmilyen előzetes elemzés használata inline hibakezelés, gyakran látni módszerek visszatérő logikai vagy numerikus „hiba” kódok, indiocating a hívónak, hogy a metjhod vagy rutin sikeres volt. Ez kiküszöböli a „funkcionális” szintaxis amelynek rutin „visszatérés” egy értelmes üzleti érték vagy objektum, (hiszen minden funkciót egyezmény vissza kell hibakódot) Amikor strukturált kivételkezelés, ez a kérdés vitás.

Strukturált kivételkezelés, Másrészről, általában nehezebb, hogy jól, mivel nem igényel elöl elemzést, hogy milyen hibák rutin vagy módszer esetleg előállítani, és, hogy milyen módszerrel lehet vagy kell tenni minden egyes hibát, ha ez nem következik be.

Egy dolog biztos, ne keverjük össze a két megközelítés egyetlen komponens ...

Válaszolt 09/12/2008 15:59
a forrás felhasználó

szavazat
1

Saját ajánlás:

Ne elkapni egy kivétel, ha:

  • Ennek elmulasztása okozna az alkalmazás összeomlik (pl egy eseménykezelő)
    • És ebben a helyzetben, feltétlenül jelentkezzen be, kivéve, hogy tudja, mi történt, és amikor
  • Meg tudod csinálni valamit, hogy megpróbálja orvosolni a helyzetet (pl végrehajtó ismétlő mechanizmus hívás esetén külső API, hogy esetenként kivételt dob ​​(megjegyzendő, hogy a kivételek kezelését nem kell használni, hogy ellenőrizzék a program áramlás))
    • És ebben a helyzetben, csak elkapni a külön kivétel típusát vársz kap dobott

Elkapta a kivétel a lehető legmagasabb szinten azt jelenti, hogy a maximális hívási verem, ami nagyon hasznos, ha megy át a naplókat, és megpróbálta, hogy milyen kezdeti intézkedés váltotta ki az események sorozata vezetett a kivétel az első helyen .

Válaszolt 09/12/2008 15:45
a forrás felhasználó

szavazat
0

Nem vagyok egy Windows-programozó, de nekem úgy tűnik, hogy a strukturált kivételkezelés kezelésére hardver kivételek, mint a szoftver kivétel azt jelenti, hogy:

  • A kód csinál valamit, hogy a C ++ szabvány nem definiált vagy megvalósítástól viselkedést (például a nullával osztás).
  • A Windows meghatározza, hogy a PSZ lehetővé tette egy kivételt dob ​​ebben az esetben.
  • Akkor használja ezt a tényt, hogy utolérjék a kivétel és / vagy végrehajtani a felmondás kezelő.

Tehát a kérdéseket feltenni, IMO, a következők:

  • Az Ön programozási feladat valóban olyan természetű, hogy a szabványos C ++ nem tud kezelni? (Vagy csak kezelni olyan módon, amely mérhetően rosszabb mit kap azáltal, hogy a hardver kivétel).
  • Valóban szükség van, hogy tegyen lépéseket, ha a kód megy, nem szabványos?
  • Tudsz írni a kódot úgy, hogy nem váltanak hardver kivételek az első helyen?

Ha a válasz „igen”, „igen”, „nem”, akkor strukturált kivételkezelés van szükség. Ellenkező esetben lehet, hogy elkerüljék azt, ebben az esetben valószínűleg érdemes. Írásban kivétel biztonságos kód trükkös, így az erősebb, kivéve garantálja tud nyújtani, annál jobb. Kód, amely talán elosztja nulla PSZ nem kínál a nothrow garancia, ha esetleg egy kis újratervezés hogy a hívók nem adnak meg Duff adatokat, akkor lehet megtenni. De ha egy funkciót már dobni kivételek egyéb okok miatt, akkor is esetleg rájuk dobott hardver csapdák meglehet, hogy a dolgok nem rosszabb.

Az egyik figyelemre méltó speciális eset memóriafoglalási. Nem biztos, hogy a .NET ezt teszi, de a linux kiosztásra csak nem sikerül, ha van elég virtuális címtartomány elosztására. Fizikai memória elkötelezett az első használatkor, és ennek hatására egy hardveres kivételt, ha nincs elég. Mivel a memória kiosztása kellene dobni std :: bad_alloc a kudarc, és a végrehajtás nem hajtja végre ezt a követelményt a szabvány, akkor lehet adni, hogy bizonyos esetekben átalakító hardver kivétel szoftver a helyes dolog. Azonban, hogy a hardver kivétel előfordulhatnak váratlan helyeken (beleértve a rutint gondoltuk, nothrow), így továbbra is lehetetlen kezelni kecsesen, ezért linux core dump helyett dobott. A gyakorlatban semmit, hogy kerül inicializálni teljesen összeomlik a kivitelező, ami gyakran elég közel van a kiosztás, hogy egy szoftver kivétel helyett hasznos lenne.

Válaszolt 09/12/2008 16:06
a forrás felhasználó

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more