Subscriber Initialise Error Handling Impovement

[srpeirce]

If you have code such as:

await subscriber.Initialise(new[] {Assembly.GetExecutingAssembly()}))
await subscriber.ListenForMessages(tokenSource);

And the subscription can't be found, the subscriber will continue to run:

info: Pat.Subscriber.SubscriptionBuilder[0]
      Building subscription 1 on service bus mailmachinegun-ns.servicebus.windows.net/...
crit: Pat.Subscriber.SubscriptionBuilder[0]
      Unable to find servicebus topic 'patAbc123' subscriber will terminate.
info: Pat.Subscriber.AzureServiceBusMessageReceiverFactory[0]
      Adding on subscription client 1 to list of source subscriptions
info: Pat.Subscriber.Subscriber[0]
      Listening for messages...
warn: Pat.Subscriber.BatchProcessing.DefaultBatchProcessingBehaviour[0]
      MessagingCommunicationException was thrown, subscriber will retry to get messages from service bus soon.

---

The current recommended is:

if (await subscriber.Initialise(new[] {Assembly.GetExecutingAssembly()}))
{
    await subscriber.ListenForMessages(tokenSource);
}

I think that subscriber.Initialise should not return a bool and should throw the Exception if it cannot initialise.
At the moment there are some occasions where it returns false and some where an Exception will be thrown which is confusing, and also leads to ability to make mistakes.

Thoughts?

[ilivewithian]

I agree that the current api isn't great for this scenario. Is it worth introducing a breaking change to fix? I'm not sure how we'd put this in as a non breaking change.

[ilivewithian]

Related to purplebricks/pat#30

[srpeirce]

I dunno, possibly overload the methods and mark the old ones as obsolete...with intention to go back and remove on next majore version?

Or adopt some other branching strategy to bundle up multiple breaking changes into a major release?

Or just bump the major version? Maybe it's not such a biggie whilst were still not massively used and will only affect a small subset of people (possibly).

Or just leave it?