Closed tebling closed 8 years ago
Thanks for pointing this out, this should never happen and if it does then it is indeed a problem.
The exception handling in PublishImpl
is there to ensure that a thrown exception by a subscriber's handler does not mess up all the other handlers and it is not there to filter the subscribers.
Let me write some tests to try to reproduce this.
Thanks! I've fixed it locally by making this change in the Subscribe method, testing that msg is of type TMsg before doing the explicit cast:
_subscriptions.Add(new Subscription(
token,
new Handler<TMsgBase>(msg => { if (msg is TMsg) handler.Handle((TMsg)msg); } )));
Yes you can use that as a temp fix however it is still throwing some errors. In the UsageExample
tests if you subscribe to the OnError
you will see the errors.
Actually you raising this issue has prompted me to re-visit some of the decisions I had made, I have now modified and improved the API slightly and also improved the way I subscribe and publish to both fix your issue as well as improving the throughput.
I am testing it at the moment and will be pushing it shortly.
Verified. Thanks for the quick turnaround!
This is a great little library - thanks for sharing!
One issue I've run across is that PublishImpl calls Subscription.Handle for each subscriber of any message type, and relies on swallowing the InvalidCastException generated for subscribers of message types other than the one being published. With the debugger attached, this affects performance greatly. I'd suggest a cleaner way of filtering subscribers based on the message type. Thanks!