Pa najbolji je koji imas u tom trenutku za tu primenu, mada se slazem da bi to moglo da se pojaca kroz nacin na koji se instanciraju i odrzavaju Multicast delegati. KOntam da prvo mraju da se dese tone bagova sa novim paralelizmom da bi obratili paznju.
A pokretanje handlera "na silu" nije pogresno a znam i zasto mislis da je pogresno (i ja sam mislio svojevremeno), zato sto o tome razmisljas kao C++ programer, kroz immediate execution, dok CLR zapravo odlaze sve sto moze
. Ja sam se doduse navikao na to jos kroz COM evente. To sto si se odjavio sa eventa ne znaci da si rekao da neces vise da primas pozive, vec da ne zelis da ih primas, zvuci slicno ali nije. U COMu npr je slicna prica, kad invoker poziva event sink prvo poziva njegov AddRef() da se osigura da event sink ne nestane u pola posla
Isto tako, ne smes da pretpostavis da ce tvoja instanca umreti onog trenutka kad tebi vise nije potrebna, sve i da nema vise zivih referenci GC moze da je odrzi u zivotu jos veoma veoma dugo (narocito ako je zavrsila u Gen2 na masini sa puno rama) a posebno sto je neko drugi u medjuvremenu mogao da uzme referencu (kao sto je ovde slucaj) pa GC ni ne moze da je pokupi. Teardown state-a o kome pricas da bi bio "koser" mora da se desi kroz disposable patern, i onda ni tu nema problema, samo kod u event handleru uokviris u
if (!disposed) {...} i problem resen, kad pravis disposable klasu na to moras svejedno da racunas, na cinjenicu da public metode, interface metode i event hanlderi MOGU biti pozvani nakon Dispose(). Ti mozes da sredis svoju klasu koja ima handler, covek koji pravi klasu sa eventom ne moze da pretpostavi ko ce sve biti kacen na njegov event i kako i mora da se osigura da event ne pukne kod njega sa {"Object reference not set to an instance of an object."}