Question: As a general rule, are there ever any circumstances in which it's acceptable for a method responsible for listening to an event to throw an exception (or allow to be thrown) that the class raising the event will have to handle?

Given that such an exception would stop other listeners to that event from being called subsequently, it seems a bit 'antisocial' to allow this to happen, but on the other hand, if there is an exception, what should it do?

Answer: 
The only two types of exceptions that should come out of events are serious, potentially process-ending ones like `System.OutOfMemoryException` or `System.DllNotFoundException`, and things that are clearly programming errors, like `System.StackOverflowException` or `System.InvalidCastException`. Catching and dropping these kinds of exceptions is never a good idea -- let them float up to the top and let the developer decide what to do with them on an application level. 

As for the rest... any common or garden-variety exception like `System.IO.IOException` should be handled inside your event, and you should have some mechanism for returning such error conditions to the caller.
Some of the answers here suggest it's bad to throw from an event handler ("creates havoc for your caller", "tends to lead to very difficult to handle situations, and unexpected behavior",...).

IMHO this is nonsense.

In the **general** case, it's perfectly OK to throw from an event handler. Other event handlers won't run of course - neither will the event handler that throws run to the end, nor any other code between the firing of the event and the point where it's caught. So what? It's perfectly normal that code is not executed when an exception is thrown - if you need to guarantee it's executed, then use a finally block.

Of course in any **specific** case you may want to consider which, if any, exceptions it is appropriate to handle, just as you would with any other code. 

As always, there are no hard and fast rules that apply in all circumstances. One of the answers here says "event handlers should be fast ... and close to error free...". A counterexample is the ASP.NET Page.Load event.

A general rule in .NET is that it's almost always a bad idea to swallow all exceptions: this applies to event handlers just as it does to any other code.

So the answer to the original question "are there ever any circumstances in which it's acceptable for a method responsible for listening to an event to throw an exception" is very definitely **yes**.

Just as the answer to the question "are there ever any circumstances in which it's acceptable for a method responsible for listening to an event to swallow exceptions" is also yes.