Ayende @ Rahien

jOHN commented on Correct event handling

Thu, 20 Nov 2008 16:43:18 GMT

Ayende, If you lock when sending the handler than you could get a deadlock. I am only trying to lock the value so it is not in an inconsitant state. I am unable to find the place where I was told this in the first place. If I recall what I was told orginally. You lock the varible and what you are coping from so the new value is in a know state. Then if the handle is released after the copy/lock the original value is still valid. If you attempt to use "handler(...)" during the call the handler could be release which would generate a error. Regards, John

Cherian commented on Correct event handling

Mon, 17 Nov 2008 10:13:54 GMT

Bart, I used to use the anonymous delegate pattern.This one is a bit tricky though. See [stackoverflow.com/.../is-there-a-downside-to-ad...](http://stackoverflow.com/questions/170907/is-there-a-downside-to-adding-an-anonymous-empty-delegate-on-event-declaration#264413)

Bart Czernicki commented on Correct event handling

Mon, 17 Nov 2008 02:30:31 GMT

I use the anonymous method trick I saw on DotnetKicks several months ago also its in Skeet's C# 3.0...its the same what Simon posted. handler = delegate {}; Just to add to this, this handler cannot be removed in C# 3.0. Not sure if 4.0 changes this, but you are guaranteed that there will always be one subscriber.

Andrés G. Aragoneses commented on Correct event handling

Mon, 17 Nov 2008 02:16:38 GMT

The best thing to do about this is having a tool (a post-compiler) like Gendarme or FxCop that warns you about it. For example: [www.mono-project.com/Gendarme.Rules.Concurrency](http://www.mono-project.com/Gendarme.Rules.Concurrency#ProtectCallToEventDelegatesRule)

Liviu commented on Correct event handling

Sun, 16 Nov 2008 19:47:32 GMT

Nobody has to write that stuff. Use postsharp for god's sake...

Ayende Rahien commented on Correct event handling

Sun, 16 Nov 2008 18:54:49 GMT

Rafal, I write about what I do.

RafalG commented on Correct event handling

Sun, 16 Nov 2008 11:27:02 GMT

Ayende, I enjoyed your posts about boo, brail, rhinos and other interesting, sophisticated, nontrivial subjects that encouraged discussion. But lately you seem to have switched to less demanding mode - short, unrelated, frequent and unsignificant stories in fire & forget manner. Maybe that's because you're very busy doing real projects, but I had to point it out. Remember, quality * quantity = const, even if the const is very big.

Krzysztof Kozmic commented on Correct event handling

Sun, 16 Nov 2008 08:09:20 GMT

You may also want to read this series of blogposts on the very same topic: [blogs.msdn.com/.../92787.aspx](http://blogs.msdn.com/jaybaz_ms/archive/2004/03/19/92787.aspx) [blogs.msdn.com/.../158636.aspx](http://blogs.msdn.com/jaybaz_ms/archive/2004/06/17/158636.aspx) [blogs.msdn.com/.../230681.aspx](http://blogs.msdn.com/jaybaz_ms/archive/2004/09/16/230681.aspx)

Ayende Rahien commented on Correct event handling

Sun, 16 Nov 2008 06:20:39 GMT

john, Event handlers are immutables, so you don't need to look them. The object that you get is always in consistent state.`

Simon Gillbee commented on Correct event handling

Sun, 16 Nov 2008 04:49:01 GMT

There's another solution that both makes the code simpler and solves the multi-threaded issue: public Action

alwin commented on Correct event handling

Sun, 16 Nov 2008 03:23:51 GMT

Shouldn't you use [MethodImpl(MethodImplOptions.NoInlining)] for your Raise() method? Else its possible that it isn't thread safe. When inlining, the local variable disappears and you could get sort of if (Completed != null){ Completed(this); } Not what you want... (Read that somewhere long ago, remembered it, googled and found [http://blog.quantumbitdesigns.com/tag/events/](http://blog.quantumbitdesigns.com/tag/events/) )

Judah commented on Correct event handling

Sun, 16 Nov 2008 01:13:46 GMT

Oren, You're right, an event with no subscribers should not throw when we attempt to raise the event. Poor design choice by the .NET guys. One workaround is a simple extension method: [stackoverflow.com/.../evil-use-of-extension-met...](http://stackoverflow.com/questions/248072/evil-use-of-extension-methods) public static void Raise(this EventHandler handler, object sender, EventArgs args) { if (handler != null) { handler(sender, args); } } (And an overload for generic EventHandlers, and you're all set.)

Mark Nijhof commented on Correct event handling

Sun, 16 Nov 2008 00:57:48 GMT

Ayende, Would you keep both null checks or just the later one? John, Should the lock not be around the whole code block to be effective? And also around any subscribing and un-subscribing code blocks? because you are not locking the variables inside the lock, you are locking that part of the code, if I understand it correctly? Please correct me if I am wrong. -Mark

john commented on Correct event handling

Sat, 15 Nov 2008 23:35:19 GMT

I was told you should lock the value during the copy since it could change at that point. Sorry I forgot where I read it. static readonly object lockObject = new object(); lock(lockObject) { handler = Completed; } if(hander != null) { handler(this); }

Phil Murphy commented on Correct event handling

Sat, 15 Nov 2008 23:25:04 GMT

I hate to have to say it, but this seems to be one of those cases where VB.NET's behaviour is better than C# - apparently "RaiseEvent" will do the multi-threaded null checking for you. Apparently. I wouldn't use VB.NET myself, you understand.

Russ commented on Correct event handling

Sat, 15 Nov 2008 23:17:17 GMT

There's still a threading issue, because an even is a multicast delegate. If there are two subscribers, the second could unsubscribe in another thread from Completed whilst handler is invoking the first; in which case handler will suffer an ObjectDisposedException. I'm not aware of any way to avoid it.

Andrew Davey commented on Correct event handling

Sat, 15 Nov 2008 23:15:28 GMT

I use a macro in Nemerle to generate this, so all I have to type is: raiseevent Completed(this) :)

Thomas Krause commented on Correct event handling

Sat, 15 Nov 2008 22:43:56 GMT

That's an easy one. If the other thread unsubscribes from the event after the condition has been checked, but before you assign the variable and there are no other subscribers, you'll assign a null reference and get a NullReferenceException.

Peter Morris commented on Correct event handling

Sat, 15 Nov 2008 22:40:07 GMT

Stood out like a sore thumb :-)

Rik Hemsley commented on Correct event handling

Sat, 15 Nov 2008 22:13:23 GMT

Just to note that R# can generate this code for you, which is handy as it's something I have to write many times a day.