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.
In an ideal word, exceptions should not exist. In a developer real word, exceptions are always expected and should be intercepted (caught), propagated or inhibited as situation asks.

So

> 
> are there ever any circumstances in
>  which it's acceptable for a method
>  responsible for listening to an event
>  to throw an exception
> 
> 
> 

Yes. You can expect an exception from every method, responsible or not to an event.

To catch almost every exception from a Windows application use:  

**[AppDomain.CurrentDomain.UnhandledException](http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx)  

[Application.ThreadException](http://msdn.microsoft.com/en-us/library/system.windows.forms.application.threadexception.aspx)**