За и против try...catch...finally

Кога е уместно понзването на try...catch...finally. Ако правилно съм разбрал

try {...}
catch(Exeption e) {...}
finally {...}

прихваща всички изключения от .NET , a

try {...}
catch() {...}
finally {...}

прихваща всички изключения и грешки.

Мисълта ми е да не се прекалява с нейното използване. Имали разумен баланс.
Операционната система ще реагира, но ако приложението работи без надзор, нощем ... не е ли добре да се подсигурим като оградим цялата програма със try {...} и при грешка да приключим коректно , без проблеми. Много функции от .NET не връщат нищо , там е оправдано ... В тоя ред на мисли имате ли подобни проблеми и как подхождате... Пример: обикновенно ехе се стартира от сървър и минава коректно, прихващат се специфични грешки. Ако се стартира програмата от друг компютър по мрежата, без права за това се появява една страховита табела с грешки и трябва да се натисне бутон за продължение. Ако обаче оградим кода с try {...} catch() {...} предотвратяваме излизането на табелата с грешки. Имали правила по които се структурира програмата или всеки преценява...

Как може да ти се налага да ползваш трайкеч.
Истинския пор-грамист не ползва трай, неговия код работи винаги.

Това с "истинския програмист" можеш да го забравиш ;-) Грешки и изключения винаги е възможно има, особено пък ако има операции по четене/запис от където и да е - кой истински програмист може да избегне да речем отпадането на мрежово устройство, препълване на EventLog (реален случай, в който гърми с изключение) и др. По отношение на заграждането в try/catch блок - идеята е че всеки catch трябва да лови възможно най-конкретния тип изключение, и евентуално ако не е фатално, "шоуто да продължи". Обаче ако е точно да няма достатъчни права, е тогава си е фатално.

За целта си правиш за абсолютно всеки изцепшън отделен кетч и си пишеш специфична логика. Също така си слагаш и throw на 2-3 места из кетчовете.

kolkoto i try catcha da slozish vse e malko. No kato gi slagash gledai da ne gi vlagash edin v drug ako e vuzmozno. A shto se otnasia do catch klauzite vurvi se ot po 4astna kum po obobshtena.

PS: Dobria programist vinagi namira vreme za Unit testove. Tuk o4akvam baia narod da izreve s zialo gurlo v zelanieto si da me oprovergae:))))

В добре замислените и реализирани библиотеки /VCL напр./ изключенията се използват от години и са естествена част от добрият стил на програмиране. Самата библиотека - също както и .NET - те принуждава да използваш изключения за писане на по кратък и елегантен код. Виж глава 18 от "Microsoft .Net Framework Приложно програмиране" на Джефри Рихтер. Софтпрес 2002 г.
MS най после разбраха, че писането на код от рода на

if (SomeFunc())
{ ...
}
else
{ ....
}
e отживелица.

Trqbva da izpolzvash Exceptionite samo za situacii v koito prilojenieto ti e preminalo v nepredviden ili ne mnogo bloagopriqten situacii.

Naprimer 4ista4kata se e spynala v kabela i nqmash dostyp do SQL servera ili do inet, ili pyk nqkoi fail koito trqbva da pro4etesh go nqma stoto HDD-to se e povredilo i ima bad sectori ili .... havna ideqta nali.
Inak ne se prepory4va izpolzvaneto na Exceptioni za slu4ai na normalna rabota na prilojenieto, naprimer ako imash textBox i nqkoi vyvede "skjsdgh" a ti o4akvash nqkakva celo4islena stoinost. V takyv slu4aj izpolzvaneto na exceptioni ne e dopustimo zaradi zabavqneto ot nqkolko sekundi koeto se polu4ava, za obrabotvaneto na stach traceto. V takyv slu4ai trqbva da izpolzvash nqkoi drug sposob.

Inak kato sa pisali po gore trqbva da si hvashtash samo tvoite exceptioni, za syotvetnoto neshto koeto pravish. I trqbva da proverqvash vinagi kakyv exception hvarlq neshtoto. Naprimer ako prashtash mail s stmp.SendMail malko ne logi4no no ste ti se hvcyrli HttpException

Have fun

Много е Джавешко. Глеам да не го ползвам, като може. Нещо в цялата концепция ми се губи, ама не знам какво. Добре поне, че не е задъжилтено да ги хендълваш изцепшъните, като в Жаба.

--
Sometimes the sole purpose of your life is to serve as a warning to others.

Доколкото аз зная хвърлянето и ловенето на ексепшъни е доста по-тежко от една проверчица. Примерно по-добре if (HashTable1.ContainsKey(...)) отколкото с try.

Ние сме точици във вселената. А всеки човек е една цяла вселена...

Е, позволи ми да не се съглася. В повечето случаи в .НЕТ, независимо дали искаш или не при грешка ще се генерират изключения, така че си длъжен да ги прихващаш.
Но дори и в класове създадени от теб според мен е желателно да ги използваш. Представи си следните 2 ситуации:
1. Имаш относителна дълга ф-я в която на на 10 места може да възникне грешка. Ако разчитам на по традиционни похвати вариантите са следните :
- if (foo() == err)
{ // извиквам др. ф-я за да се справи с грешката
return false;
}
- if (foo() == err) goto ErrOccured;
....
ErrOccured;
// извиквам др. ф-я за да се справи с грешката
return false;
2. Имаш йерархия от класове или няколко отделни класа в които един метод извиква др. метод, който извиква др. метод и т.н. При всяко извикване на метод трябва да проверяваш как е завършил - успешно или не. Какъв % от кода ти ще е за тези проверки ?

говорех по-скоро за случаи, в които да прескочиш рейзването на ексепшън. Т.е. примерно
string s = "12k300";
try
{
int i = int.Parse (s); //raise-ва ексепшън
}
catch(....)
{...}
e по-зле от
string s = "12k300";
if (s.IsNumeric)
{
int i = int.Parse (s);
}
Mакар и такива точно случаи да могат да се избегнат по принцип.

Ние сме точици във вселената. А всеки човек е една цяла вселена...