Analizez din când în când un fișier care are date MalFormed.

depășirea

și aruncă o excepție,

Aș dori să mă recuperez de la excepție și să ignor datele greșite formatate.

Care este cel mai bun mod de a face acest lucru?

* EDIT: * Cred că întrebarea mea nu a fost înțeleasă bine. Aș dori să mă recuperez de la excepție, orice excepție, nu vreau ca programul meu să se oprească. dar să continui.

8 Răspunsuri 8

Cred că ceea ce întrebi este următorul:

Când analizați un fișier linie cu linie, uneori linia curentă are date greșite, ceea ce face ca o excepție să fie aruncată în codul dvs. Poate că trebuie pur și simplu să vă structurați codul astfel încât try/catch să înconjoare doar codul de analiză, nu codul de citire a liniei. De exemplu:

Blocul exterior try/catch este acela de a gestiona închiderea corectă a obiectului cititor dacă s-a întâmplat ceva când ați încercat să deschideți sau să citiți fișierul. Blocul de încercare/captură internă este de a înghiți excepțiile ridicate dacă datele citite au fost malformate și nu au putut fi analizate corect.

Totuși, sunt de acord cu aproape toți ceilalți. Înghițirea excepției ar putea să nu fie bună. Cel puțin, vă recomand să o conectați undeva.

Pe scurt, probabil că nu ar trebui să folosiți excepții pentru acest lucru. Ceva ca un TryParse care returnează fals este mult mai eficient și mai ușor de recuperat. Manevrarea excepțiilor este o abordare puțin obișnuită.

În general, ceva de genul acesta:

Ar trebui să evitați prinderea cazului general de excepție și, în schimb, să prindeți o excepție specifică, oricare ar fi aceasta.

Răspuns scurt: excepțiile sunt scumpe de utilizat în acest mod. Dacă este posibil, testați intrarea înainte de a o trimite pentru procesare și nu ignorați acolo decât să ignorați excepțiile.

De asemenea, asigurați-vă că nu aruncați o rețea prea largă și nu mâncați excepții legitime despre care ați putea dori să aflați.

Prinderea unei excepții generale este o idee proastă dacă vă așteptați să arunce doar unul sau două tipuri de excepții specifice pentru erori specifice analizei. De obicei, este mai bine să prindeți fiecare tip de excepție specific și să îl gestionați independent, astfel încât codul dvs. să nu suprime nicio altă eroare (poate neașteptată) (de exemplu, dacă fișierul lipsește sau o conexiune la rețea expiră, acesta ar trebui tratat în la fel ca și cum fișierul conține date corupte?)

Cu toate acestea, prinderea unei excepții generale este o idee minunată dacă aveți în mod deliberat nevoie/doriți să prindeți toate erorile posibile și să continuați cu grație. Acest lucru se poate întâmpla dacă tratarea tuturor tipurilor de erori este aceeași (de exemplu, „dacă, din orice motiv, nu pot citi această valoare de preferință, voi returna valoarea implicită de 5” - asta este infinit mai bun decât programul dvs. care se blochează, deoarece nu ați făcut ' Nu-mi dau seama că ar putea genera o excepție din cauza unui timeout al rețelei). Dacă este utilizată cu înțelepciune, această abordare poate face ca programul dvs. să fie antiglonț - dar dacă este folosit în mod neînțelept, puteți suprima erorile despre care trebuie să știți și să remediați, iar acest lucru poate fi foarte dureros.

Când eliminați orice excepție, ar trebui să luați întotdeauna în considerare cu atenție raportarea erorilor - ar trebui să spuneți utilizatorului că ați avut o problemă? Ar trebui să îl conectați într-un fișier de urmărire, astfel încât atunci când un client se plânge de ceva care nu funcționează corect, puteți urmări înapoi la sursa problemei? Sau ar trebui să îl ignori în tăcere? Doar fiți atenți, deoarece suprimările excesive de zel pot face foarte dificil să aflați de ce un progam se comportă imprevizibil.