C#-ban mennyire erőforrás igényes dolog a try-catch használat?

Én úgy tapasztaltam - még 3.5 idején - hogy eléggé. Egyik projektemnél az egyik TreeView láthatóan lomhán nyitogatta az újabb elemeket, mint kiderült, a lista feldolgozásakor (egy ciklus közepén...) valahol null értékekkel találkozott, és ezt csak catch ágban kezelte le a programozó. Amint ezt korrigáltam, gyors lett.

Nem tudom, hogy újabb verzióknál javítottak-e a teljesítményén, de általában véve az Exceptionöket érdemesebb "értelmesebb módon" kezelni, és csak a tényleg váratlan esetekben használni. Például egy opcionális JSON struktúra mezőnél inkább ellenőriznék, míg teszem azt egy függvény nem opcionális argumentumainál nem.

Ha nem történik kivétel, akkor egy nagyon-nagyon minimális csökkenés van.

Kivételkezelés esetén pedig igen, eléggé erőforrás igényes - de elvégre azért kivétel-kezelés. Ha egy program "normál" működés során kivételeket dobál, akkor az a program rosszul van megírva.

Ne akarj nullreference-t elkapni, IF-el nézd meg, hogy adott cucc null-e. Try-catch-re építeni pocsék tervezés :)

A try-catch hibakezelésre való, nem IF helyett használni.

Hibakezelésre természetesen ajánlják, hiszen arra való. De arra használni, hogy azzal generálj eventet vagy kvázi elágazásra nem való. Megszakítja a program működését, erőforrás igényes nagyon. A feladatára nagyon jó, másra nem :)

"Ez végső soron elágazás, hiszen vagy át lehet alakítani, vagy nem, és ezt lehet róla tudni, de sokkal egyszerűbb átalakítani és egy excepttel elkapni, ha nem lehet, mint a programozó saját eszközeivel szintaktikai elemzést végezni a stringen. Ez gazdaságtalan?"

Ez helyzettől függ. Ha a rendszer egy olyan, backend rétegéről beszélünk, ami már szűrten kapja az adatokat, és elvileg már csak számokat kap, akkor ott a kivételkezelés teljesen helyes megoldás. Ha viszont arról van szó, hogy nagy mennyiségű adatot olvasunk be mondjuk, és az adott mezőben elvileg számok vannak, de gyakran előfordul egyéb karakter is, akkor ott a kivételkezelés eléggé lelassíthatja a folyamatot, tehát arra nem praktikus megoldás.