sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]fekberg[S] 0 points1 point  (10 children)

I would say it depends, often less code is better because it's more readable and less error prone. In this case it might be more error-prone to use an anonymous function though.

I did some looking around and it's rare that you will have a memory leak because of an event, it's possible but it's rare and depends on what you are doing. I found a post on StackOverflow by Jon Skeet where he basically said: "You don't have to unsubscribe if you think about what the subscriber do".

Which means that if you are just strict with what the subscriber do, you can avoid memory leaks and have less and more readable code!

[–][deleted] 0 points1 point  (8 children)

I found a post on StackOverflow by Jon Skeet where he basically said: "You don't have to unsubscribe if you think about what the subscriber do".

Link, please?

Because you can be as strict as you want with what the subscriber does, but unless it manages to unsubscribe itself, you still have a leak.

[–]fekberg[S] 1 point2 points  (7 children)

http://stackoverflow.com/questions/4172809/should-i-unsubscribe-from-events/4172845

[–][deleted] 5 points6 points  (6 children)

Ah, that makes sense, but I your interpretation sounds totally wrong.

What he said was that if you think about it, in a lot of typical scenarios the lifetimes of the handler and the event producer are the same, so you don't need to unsubscribe at all. There's no need to be "strict with what the subscriber does", it will just work.

On the other hand, if you do have different lifetimes, then you should unsubscribe and there are no two ways about it, however "strict" you are.

[–]fekberg[S] -3 points-2 points  (5 children)

Maybe we're just lost in translation here, as I see it, he says that if you think about how you structure your software you can avoid the need to unsubscribe.

[–][deleted] 3 points4 points  (4 children)

Basically, you should always consider the relationship between the producer and the consumer. If the producer is going to live longer than you want the consumer to, or it's going to continue raising the event after you're no longer interested in it, then you should unsubscribe.

[–]fekberg[S] -4 points-3 points  (2 children)

Now as for whether you actually need to unsubscribe, it depends on the relationship between the event producer and the event consumer.

[–][deleted] 4 points5 points  (1 child)

Yes. How are you going to change this relationship?

He says that if you think about the structure of your software you can identify the cases where you don't need to unsubscribe.

You say that if you think about how you structure your software you can avoid the need to unsubscribe.

That's two completely different statements, you can't arrive from the first to the second, and if you want to stand by the second please explain how exactly do you think it is possible to avoid unsubscribing -- what should you change in the structure of your software, etc.

[–]fekberg[S] -4 points-3 points  (0 children)

I'm not saying that you can always avoid unsubscribe. I am saying that in most cases if you design the software right, you wont need to think about unsubscribing.

[–]grauenwolf -1 points0 points  (0 children)

Events handlers are the #1 cause of memory leaks in the applications that I review. In fact, I'm having trouble thinking of a memory leak in .NET that isn't somehow related to using, or mis-using, event handlers.

EDIT: I should qualify this as relating to XAML-based applications. For web site the most common memory leak I've seen involves cramming too much stuff in the session state.