C #: pasirinktinių išimčių maišymas

Aš perskaičiau keletą kitų klausimų, susijusių su C # išimties tvarkymo praktika, bet niekas neatrodo paklausęs, ko aš ieškau.

Jei aš įgyvendinu savo išimtį konkrečiai klasei ar grupei. Jei visos su šiomis klasėmis susijusios klaidos būtų įtrauktos į mano išimtį, naudojant vidinę išimtį, ar turėčiau leisti jiems nepavykti?

Maniau, kad būtų geriau sugauti visas išimtis, kad išimtis būtų iš karto atpažįstama iš mano šaltinio. Aš vis dar išlaikau pradinę išimtį kaip vidinę išimtį. Kita vertus, maniau, kad būtų nereikalinga atsisakyti išimties.

Išimtis:

 class FooException : Exception { //... } 

1 parinktis: „Foo“ užmaskuos visas išimtis:

 class Foo { DoSomething(int param) { try { if () { //violates business logic etc... throw new FooException("Reason..."); } //... //something that might throw an exception } catch (FooException ex) { throw; } catch (Exception ex) { throw new FooException("Inner Exception", ex); } } } 

2 parinktis: „Foo“ išskleidžia tam tikras „FooExceptions“, tačiau leidžia praleisti kitas išimtis:

 class Foo { DoSomething(int param) { if () { //violates business logic etc... throw new FooException("Reason..."); } //... //something that might throw an exception and not caught } } 
45
21 янв. nustatė user295190 21 sausis 2011-01-21 19:30 '11 19:30 val. 2011-01-21 19:30
@ 8 atsakymai

Remdamasis patirtimi su bibliotekomis, viskas (ką tikitės) į „ FooException turi būti FooException dėl kelių priežasčių:

  • Žmonės žino, kad jis atėjo iš jūsų darbo, arba bent jau nuo jų naudojimo. Jei jie mato FileNotFoundException , jie gali žiūrėti į viską. Jūs padedate jiems susiaurinti. (Dabar suprantu, kad kamino pėdsakai yra šiam tikslui, todėl galbūt galite ignoruoti šį punktą.)

  • Galite suteikti daugiau konteksto. Įtraukdami FNF į savo išimtį, galite pasakyti: „Bandžiau atsisiųsti šį failą šiam tikslui ir jo neradu. Tai rodo galimus teisingus sprendimus.

  • Jūsų biblioteka gali tinkamai tvarkyti valymą. Jei leisite išimties burbulą, priversite vartotoją išvalyti. Jei tinkamai užsandarinote tai, ką darote, jie neturi idėjos, kaip elgtis su situacija!

Nepamirškite tik supakuoti tikėtinas išimtis, pvz., „ FileNotFound . Ne tik suvyniokite Exception ir tikiuosi geriausiu.

53
21 янв. Atsakymas suteiktas Tesserex sausio 21 d 2011-01-21 19:36 '11, 19:36, 2011-01-21 19:36

Pažvelkite į geriausius MSDN metodus .

Tarkime, kad vietoj throw ex naudokite throw jei norite vėl mesti sugautas išimtis, nes tokiu būdu išsaugoma originali stotelės lentelė (eilutės numeriai ir tt).

18
21 янв. Atsakyti Tim Schmelter Jan 21 2011-01-21 19:37 '11, 19:37, 2011-01-21 19:37

Kuriant priskirtą išimtį, aš visada pridedu keletą savybių. Vienas iš jų yra vartotojo vardas arba ID. Pridėjau „DisplayMessage“ savybę, kad apvyniotų naudotojui rodomą tekstą. Tada aš naudoju žinutės savybę, kad techniniai duomenys būtų siunčiami į žurnalą.

Aš užfiksuoju kiekvieną duomenų prieigos lygio klaidą tokiu lygiu, kur galiu vis dar užfiksuoti išsaugotos procedūros pavadinimą ir perduotų parametrų reikšmes. Arba įterptas SQL. Galbūt duomenų bazės pavadinimas arba dalinis ryšys (be įgaliojimų). Jie gali būti rodomi pranešime arba savo naujame „DatabaseInfo“ naudotojo nuosavybėje.

Tinklalapiams naudoju tą pačią pasirinktinę išimtį. Į informaciją apie formą įkelsiu informaciją - tai, ką vartotojas įvedė į kiekvieną tinklalapio duomenų įvedimo kontrolę, redaguojamo elemento (kliento, produkto, darbuotojo ir kt.) Identifikatorių ir vartotojo veiksmus, kai įvyko išimtis.

Taigi, mano strategija dėl jūsų klausimo: tiesiog sugauti, kai galiu ką nors padaryti dėl išimties. Ir gana dažnai viskas, ką galiu padaryti, yra registruoti duomenis. Taigi, aš tik sugauti tą vietą, kur šie duomenys yra prieinami, ir tada rekonstruoti, kad pašalintumėte burbulo galimybę vartotojo sąsajoje. Ir aš išsaugoju pradinę išimtį įprasta išimtis.

5
21 янв. atsakymas pateikiamas DOK sausio 21 d 2011-01-21 19:44 '11, 19:44, 2011-01-21 19:44

Pasirinktinių išimčių tikslas yra pateikti išsamią kontekstinę informaciją, skirtą stacktrace, kad padėtų derinti. 1 variantas yra geresnis, nes be jo jūs negalėsite gauti „išimties“ išimties, jei ji įvyko „žemiau“.

3
21 янв. Dave Swersky atsakymas dėl sausio 21 d 2011-01-21 19:34 '11, 19:34, 2011-01-21 19:34

jei „Visual Studio“ paleidžiate kodo fragmentą „Išimtims“, turite rašymo ištraukimo praktiką.

1
21 янв. Atsakymą pateikė Felice Pollano . 2011-01-21 19:34 '11, 19:34, 2011-01-21 19:34

Svarbiausia, kad kodas, kuris turėtų žinoti, kada aptinkama išimtis, kuri, deja, išimties objekte visiškai nėra, yra sistemos būklė, ką ji turėtų "(tariamai išimtis buvo išmesta, nes buvo kažkas negerai). „LoadDocument“ metodo klaida, manoma, kad dokumentas nebuvo įkeliamas sėkmingai, tačiau yra bent dvi galimos sistemos nuostatos:

  1. Sistemos būsena gali būti tarsi atsisiuntimas niekada nebuvo atliktas. Tokiu atveju būtų visiškai teisinga, jei programa tęstųsi, jei ji gali tai padaryti be įdėto dokumento.
  2. Sistemos būklė gali būti gana iškreipta, kad geriausia būtų išsaugoti, ką galite išsaugoti atkūrimo rinkmenose (nepakeiskite gerų naudotojo failų su sugadintais duomenimis) ir išeikite.

    Akivaizdu, kad tarp šių kraštutinumų dažnai yra kitų galimų būsenų. Siūlyčiau, kad būtų siekiama sukurti ypatingą išimtį, kuri aiškiai nurodo, kad egzistuoja # 1 būklė, o galbūt ir # 2, jei tai gali lemti nenumatytas, bet neišvengiamas aplinkybes. Bet kokios išimtys, atsirandančios ir rezultatas # 1 būsenoje, turėtų būti suvyniotos į išskirtinį objektą, nurodantį būseną # 1. Jei išimtis gali įvykti taip, kad sistemos būklė gali būti pažeista, jie turi būti suvynioti į # 2 arba išspręstą perkolaciją.

1
22 марта '11 в 21:21 2011-03-22 21:21 atsakymas pateikiamas supercat kovo 22 d. 11 val. 21:21 2011-03-22 21:21

Pastaba 1 variantas: throw new FooException("Reason..."); nebus sugauti, nes jis yra už bandymo / sugavimo bloko ribų

  • Turėtumėte sugauti tik tas išimtis, kurias norite tvarkyti.
  • Jei nepridėsite jokių papildomų duomenų, išskyrus naudojimą throw; nes ji nežudys jūsų kamino. 2 variante vis dar galite atlikti apdorojimą viduje ir tiesiog skambinti throw; atkurti pradinę originalaus kamino išimtį.
1
21 янв. Atsakymas, kurį pateikė Jakub Konecki, sausio 21 d 2011-01-21 19:34 '11, 19:34, 2011-01-21 19:34

2 variantas yra geresnis. Manau, kad geriausia praktika yra išskirti tik tada, kai planuojate ką nors daryti su išimtimi.

Tokiu atveju 1 galimybė paprasčiausiai išskiria tik savo išimtį. Tai neduoda jokios vertės, o jūsų klasės vartotojai nebegali tiesiog perimti „ArgumentException“, pavyzdžiui, jie taip pat turi sugauti „FooException“ ir tada išnagrinėti vidinę išimtį. Jei vidinė atskirtis nėra išimtis, jie gali padaryti kažką naudingo ir juos reikės iš naujo nustatyti.

0
21 янв. atsakymas pateikiamas btlog sausio 21 d 2011-01-21 19:35 '11, 19:35, 2011-01-21 19:35

Peržiūrėkite kitus klausimus apie etiketes arba Užduokite klausimą