When to use Weak Events?

Question

I was refering MSDN tutorial on weak events. I understood the basics. I am working on a non-WPF project and my class is exposing certain events. My question is that does the weak events completely replace old event pattern? Is it good to use it every classes that is exposing events? What are the side effects of using weak events liberally?

Tantalous

Nothing is getting replaced, it is just a hack around a leak you'll get when the event source object outlives the event subscriber object and the subscriber object is sloppy about unsubscribing the event. – Bron

Events should always be weak references... but unfortunately they're not by default. MS has a class that handles events using weak references, but unfortunately its syntax is atrocious. Thankfully, though, there's an event library that gives a simple syntax for weak events, along with a few other improvements to events (eg. simple to have multiple publishes to the same event, removes unnecessary coupling, etc) – Description

Answer 1

Based on the reading I have done, there does not appear to be any specific negatives to using WeakEvents, except for the fact that it is more verbose to do so. Additionally, you should be able, in most cases, to manually unregister from events when you no longer need them. In some cases, this won't be possible. For example, the MSDN page you reference mentions when you should use WeakEvents:

http://msdn.microsoft.com/en-us/library/aa970850.aspx

Certain scenarios inherently lend themselves to the application of the weak event pattern. One such scenario is data binding. In data binding, it is common for the source object to be completely independent of the listener object, which is a target of a binding. Many aspects of WPF data binding already have the weak event pattern applied in how the events are implemented.

The only person who has presented any type of negative to them is this blog:

http://blog.catenalogic.com/post/2011/11/23/A-weak-event-listener-for-WPF-Silverlight-and-Windows-Phone-7.aspx

There are a few downsides about using a weak event listeners in general:

• It’s notation is ugly, the “original” .NET way looks way better
• You have to name the event by string, that sucks (if you know a better way, contact me!)
• It can only handle events with a handler of EventHandler
• You become a lazy developer not caring about subscriptions

Essentially, they should be used for events that your objects will subscribe to for the entire length of their existence, and only disconnect from when the objects are disposed. For everything else, using the traditional events and registering/unregistering the events manually is preferred.

Kkt

This is the new link catelproject.atlassian.net/wiki/display/CTL/Weak+events – Calcicole

Unfortunately, a serious risk has been discovered since this answer was written. See The Weak Event Pattern is Dangerous, as referenced in Ladi's answer. Worse, the risk is unpredictable, and according to that article, if it happens, the result may be dangerous behavior that is difficult to find the cause of. – Delindadelineate

Answer 2

There are two issues that must be considered with weak events:

1. Weak events allow subscribers to subscribe to events (messages) even without knowing the identity of the class raising the event. In some cases that may be desired even necessary. However, in some cases that can introduce unnecessary complexity and a level of indirection that makes the code harder to manage or control at run time.
2. The major downside of using weak events is that it may encourage developers to neglect the part where they unsubscribe from events (messages). In that case event handlers may be invoked even after the subscribers "go out of scope". Consider a subscriber that does not explicitly unsubscribe and that becomes garbage collectable but was not yet garbage collected. The weak event manager will not be able to detect that state and because of that it will still call the event handler of that subscriber. This can lead to all kind of unexpected side effects.

See more details at The Weak Event Pattern is Dangerous.
See this source code that illustrates this issue using the MvvMCross messaging plugin as a weak event manager.

Markson

This answer directly contradicts your conclusions. You based your article on all implementations of the weak event pattern using long weak references. Implementations that erroneously do use long weak references are broken and will exhibit the behavior you described, but correct implementations will use short weak references which are not capable of being resurrected. – Cnossus

Answer 3

When to use weak events?

From MSDN

Listening for events can lead to memory leaks

So you should use weak events with the purpose of avoiding those leaks

Is it good to use it every classes that is exposing events? What are the side effects of using weak events liberally?

See Why is the implementation of events in C# not using a weak event pattern by default?. Leaking from "strong" events is not that usual, weak events come with a performance cost and have a semantic difference that may not be desired in every context, misuse of a weak reference can cause the event to intermittently not to fire (in contrast to misusing a normal event causing a memory leak)

Example memory leak that could be avoided

Static classes and Singletons are villains when talking about memory leaks, when they acquire a reference to some other object they will prevent the object from being garbage collected, and thus, leak the object forthe lifespan of the application, here is an example where I met with the need for a weak reference to avoid a memory leak

Doily

Answer 4

First of all, weak events are not always necessary, like others have been saying only when the source object outlive the subscriber. If that is the case, then yes, you should use it, this is what people call The Weak Event Pattern.

The side effects are just that you will have to write more code. Microsoft provides the WeakEventManager class and in WPF exist some specific implementations, but you can create your own inheriting from the base WeakEventManager.

The way it works is by using weak references from the source object to the listener so this relationship doesn’t stop the GC from collecting these objects. For some specific applications this can solve a lot of performance issues.

Orcus