tag:blogger.com,1999:blog-8259613.post115602165804126348..comments2023-08-05T11:16:50.347+02:00Comments on Kristof Verbiest - Bite-size C#: A better way to raise eventsKristofhttp://www.blogger.com/profile/01727380410232817527noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-8259613.post-71909273052057548142012-03-13T18:08:29.656+01:002012-03-13T18:08:29.656+01:00@James I agree that try/catch is not a good approa...@James I agree that try/catch is not a good approach.<br />Your approach (using callback functions) is unconventional but may work. However, if you need to support multiple subscribers, this does not work. But in some situations this will defenitely help to avoid memory leaks due to dangling subscriptions.Kristofhttps://www.blogger.com/profile/01727380410232817527noreply@blogger.comtag:blogger.com,1999:blog-8259613.post-9747584549185854522012-03-13T15:21:26.240+01:002012-03-13T15:21:26.240+01:00try/catch is the worst approach! Copying it is be...try/catch is the worst approach! Copying it is best if you have to do events in multi-threaded environment.<br> But a better approach is to never use events with multi-threading. Use delegates like callback functions directly!<br> Leave events to the UI thread. And if you aren't on the UI thread, invoke your function onto the UI thread before invoking an event.<br>This also eliminates potential issues with event handler/memory leaks from unreleased event binding (which can be a pain in multi-threading).Jameshttps://www.blogger.com/profile/05629735656403232435noreply@blogger.comtag:blogger.com,1999:blog-8259613.post-43679239640143999512008-10-22T18:39:00.000+02:002008-10-22T18:39:00.000+02:00many will suggest this is bad design, but to avoid...many will suggest this is bad design, but to avoid both potential issues, as anon #2 suggest, wrap the event invoke in a try/catch. <BR/><BR/>you don't have to make a copy, and you don't have to worry that the consumer is in the wrong state. (the consumer would invariably have been the one to unsubscribe from the event if it is now null)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8259613.post-91288377079069561552008-06-21T12:28:00.000+02:002008-06-21T12:28:00.000+02:00Why not locking the event?The pattern you and (as ...Why not locking the event?<BR/>The pattern you and (as my college anonymous noted) Microsoft are suggesting exposes a potential bug:<BR/>In the case a context switch occurred after you've made a copy of the event handler, and another thread removes an observer from the list. This observer is now not expecting to receive event calls of this event and might have moved to a different operation state. Your pattern will cause undesirable behavior by sending him the event and this might cause unexpected results.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8259613.post-90230820530967883622008-03-31T22:26:00.000+02:002008-03-31T22:26:00.000+02:00You may also note that there is a code snipped for...You may also note that there is a code snipped for this (at least in VS2008)<BR/>just type "invoke" and press TAB TABAnonymousnoreply@blogger.com