Zjistil jsem, ze jsem udelal obrovskou chybu, kdyz jsem si nechal obsluhu vyjimek az na posledni chvili, kdy je vse ostatni hotove. Mam aplikaci, kde mam nejakou grafickou cast (projekt GUI), a potom 13 dalsich projektu, ktere spolu nektere souvisi a nektere ne. Mezi temito projekty a GUI je Spravce projektu, coz mel byt puvodne jediny projekt, se kterym by GUI komunikovalo primo, a ktery by videl na vsechny ostatni projekty a tvoril takovy ridici prvek. Pozdeji, protoze nebyl dostatek casu na analyzu, jsem trosku polevil a tak nektere projekty napriklad s projektem Databaze nebo Nastaveni komunikuji primo, ne pres spravce.

Tak a ted resim problem, jak co nejjednoduseji (nejrychleji) navrhnout nejaky system obsluhy vyjimek. Potrebuji nejake centralni misto, ktere bude odchytavat vsechny moje specialni vyjimky, generovat zpravy o chybovych stavech a rozhodovat, co dal. A navic potrebuji, abych byl schopen v GUI dostat nejaky impuls, kdyz nastala nejaka vyjimka, o ktere musim informovat uzivatele (zapsat do vypisu zprav a upozorneni, ktery je v hlavnim okne aplikace), restartovat aplikaci apod.

Mohu Vas pozadat o nejake tipy, ze ktereho smeru to zacit resit. Mam na to cca dnesni den. Jinak vse to mam udalostmi resene, veskerou komunikaci mezi jednotlivymi moduly (projekty).

Za predpokladu, ze pouzivas vhodny zpusob komunikace by bylo nejjednodussi vyjimky zobrazovat v GUI jejich zachycenim pres komunikacni kanal na dany modul (na strane GUI).
Zobrazeni vyjimky pak muzes provest treba metodou s argumentem typu Exception a tuto metodu pouzit vsude, kde je treba, nebo pouzit post-compiler / message sink (v podstate by slo take o metodu, ale nebylo by treba zasahovat do existujiciho kodu).
Na druhou stranu logovani by melo byt provedeno nejlepe pri zjisteni chyby (tedy primo v modulech). Navic kazdy modul ci metoda obvykle ocekava jine vyjimky.

Pak bys mohl jeste chtit zalogovat nezpracovane vyjimky - Application.ThreadException (pro WinForms).
Pripadne Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException) + AppDomain.CurrentDomain.UnhandledException.
Tyto nejspis jen zalogujes bez zobrazeni uzivateli, pripadne zobrazis vlastni okno s vyjimkou.

Chtel jsem to vymyslet nejak tak, ze ke kazdemu modulu pripojim ten modul pro centralni zpracovavani chybových stavů. Kdyz nastane vyjimka, vzdycky zavolam nejakou metodu tohoto centralniho modulu (neco ve smyslu ZpracujVyjimecnyStav), kteremu predam danou vyjimku a mozna informaci o tom, jak moc je chyba zavazna. Pokud o tom ten modul muze rozhodnout. A tento centralni modul pak provede napr. zalogovani do souboru, a posle udalostii informaci do GUI, ktere pak muze zobrazit info uzivateli apod.

Post-compiler a message sink jsem nikdy nepouzil a popravde ani poradne nevim, o co jde.
Zatim diky za tipy.

Erwoll: udelal bych to tak, jak pises v predchazejicim prispevku. GUI se to dovi specialni udalosti, logovaci modul to zaloguje.

Na kazdou vyjimku vetsinou budes reagovat dle kontextu, takze centralni zpracovani vyjimek asi neni vhodne.
Ne o kazde vyjimce bude chtit GUI vedet (proto jsem psal, ze bych zobrazovani vyjimek resil az v GUI pri komunikaci) - v zavislosti na kontextu.

Pokud si chces ulehcit praci tak to klidne udelej tak, jak jsi psal. Fungovat to bude a take nebude problem to v pripade potreby zmenit. Urcite bych to ale udelal spis jako logovaci tridu (ne jako osetreni vyjimek).
Na te tride si pak nadefinujes event, GUI se prihlasi k odberu a vyfiltruje si, co potrebuje (pokud to pujde)... Na GUI treba posles jen vyjimky s urcitou urovni dulezitosti.
Osobne bych to tak nedelal hlavne kvuli absenci kontextu - obzvlast u GUI interakci. Vetsinou bys uzivateli dal spoustu informaci, ktere nepotrebuje a mozna zadne, ktere vedet chce.

Jinak je to obycejny logovaci mechanismus jako v milionech jinych projektu... Mel jsem pocit, ze Ti jde spis o reseni zobrazovani zprav uzivateli.

Tak nakonec jsem to nemohl udelat presne tak, jak jsem si predstavoval, protoze ten navrh aplikace je proste spatnej, kdyz se na nej zpetne divam. Jak se rika po kazdem projektu:"Ted bych to udelal cele uplne jinak". Kvuli kruhovym referencim a podobnym chutovkam jsem nemohl jednoduse zaclenit logovaci modul a nechtel jsem ho nasilne cpat do nejakeho uz existujiciho modulu, protoze by to pro me bylo neprehledne.

Reseni, ktere jsem pouzil je opravdu hnusne a doufam, ze neopusti steny tohoto fora Kazdy modul pri vytvareni fasady dostane jako argument delegata logovaci metody (parametr pointer na metodu). A v pripade potreby zalogovani jen zavola tuto metodu. Takhle to probubla az do modulu pro logovani, ktery provede zalogovani do interniho souboru (tam jsou vsechny potrebne informace pro programatora, pri reseni chyb aplikace, jako je vypis stack trace apod.), pokud ma uzivatel zapnute logovani i pro sebe, tak nektere informace se zaloguji i do uzivatelskeho logu.

Ta metoda (tu co si posilam jako parametr) ma jako parametr objekt, ktery rozsiruje EventArgs, takze v miste chyby muzu specifikovat, o jak zavaznou chybu se jedna, tim jak to probublava, se muze tento status menit, protoze na urovni tridy to je treba zavazna chyba, ale tato trida nevi, ze se potom tento stav osetruje treba na urovni modulu, ktery si s tim uz umi poradit, a tak zmeni status z kriticke chyby na nejakou slabsi variantu.

Dale muzu menit i uzivatelskou zpravu. Tu nemusim zadat vubec na urovni tridy, ale jakmile probublavam vys, tak vim, co chyba zpusobila z pohledu uzivatele, a mohu ji doplnit o pro nej relevantni informace. No a do GUI uz prijde jen informace o typu chyby (zavaznost), cas a uzivatelska zprava. Nektere chyby se tak k uzivateli vubec nedostanou, protoze pro nej nejsou uzitecne.

Jediny problem, ktery nastal (dost podstatny), jsou singleton tridy (vetsinou jadra modulů), ktere maji static konstruktory a tak jim nemohu predat tuto metodu. Zatim jsem to vyresil tak, ze ty static konstruktory budou prazdne, a protoze tyto singleton tridy pouzivam az pri vytvoreni fasady nad nimi, tak ihned po jejich prvnim pouziti (tim padem zavolanim statickeho konstruktoru) ve fasada zavolam inicializaci jadra (inicializace objektu, ve kterych muze nastat chyba). V tu chvili uz totiz muzu predat jadru logovaci metodu.

Vim, ze to je strasne harakiri, a defakto jsem sahl na kazdy kousek kodu. Tedy minimalne do kazdeho modulu.