Ne emelj (raise) kivételeket (exception), mert az erőforrásigényes (lassú).

A továbbiakban tartózkodok a zárójelektől. :)

Kivétel, benne van a nevében, csak kivételes, nem várt helyzetekben kell használni. Ennek ellenére vannak programozók, akik úgy hiszik nincs kúlabb kommunikációs forma a hívó és a hívott között, mint kivételt hányni az arczába. Cool biztos, és piszok lassú is.

Megint csak egy third-party gyártó vezérlőit használó appban láttam profilerrel, hogy az exceptionök kezelése igen sok időt elvitt a form felépüléséből. Csak az nem volt világos, miért kell ezerszámra exceptionöket dobni a vezérlőnek? Az egyik konstruktora ugyanis dobálta a NullReferenceException-öket, amit aztán elkaptak belül, de ettől még lassú lett a program.
Még profiler se kell az ilyen sunyi kivételdobálókat elcsípni, mert az Output Window tele van az ő exception-jeikkel, 1254 egy form open során.
Javasoltam a szerző cégnek, javítsák ki, mert nem normális, hogy egy library ennyi exceptiont dobjon és nyeljen el. Ez meglepően sok időt elvitt, és nagyon sok ágon megjelent a profilerben a nyoma.

A gyártó átírta a kódját, és láss csodát, kb. 3x gyorsabban töltődött be a form. 10 mp helyett 3mp nagyon nagy különbség ám pszichológiailag.

Konklúzió: ésszel azokkal az exceptionökkel, csak arra használjuk őket, amire tervezték.

Ehhez kapcsolódik még, hogy néha egy rosszul megírt API kényszerít minket felesleges exceptionkezelésre. A .NET Fw. 1.x-ben még csak olyan pl. Int32.Parse(string) volt, ami exceptiont dobott, ha nem volt megfelelő a kapott sztring. Képzelj el mondjuk egy csv olvasó programot, ami milliónyi sort olvas fel, egyes oszlopokat számmá alakítva. Ha mondjuk a sorok 10%-a hibás, százezer exceptiont kell elkapnunk. Meglesz az ára.

Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.