[FEATURE REQ] Azure Service Bus Enforce mandatory processor arguments on CreateProcessor

Right now I can do the following

await using var receiver = serviceBusClient.CreateProcessor(destination, optionalOptions);
receiver.ProcessMessageAsync += async processMessagesEventArgs =>
{
    // processing logic
};

but if I try to start this I get a runtime exception telling me

Unhandled exception. System.InvalidOperationException: Cannot begin processing without ProcessErrorAsync handler set.
   at Azure.Messaging.ServiceBus.ServiceBusProcessor.ValidateErrorHandler()
   at Azure.Messaging.ServiceBus.ServiceBusProcessor.StartProcessingAsync(CancellationToken cancellationToken)

given that only ever one handler can be assigned, which is enforced by

https://github.com/Azure/azure-sdk-for-net/blob/6e4c8ea877c94adf7279c0c8ca458dd69ccadee6/sdk/servicebus/Azure.Messaging.ServiceBus/src/Processor/ServiceBusProcessor.cs#L289

why not enforce the two required handler parameters as input to CreateProcessor? How useful is it that those two are exposed as “event handler delegate” that are not really event handler delegates (because normally you could have multiple, here you can’t) and in all the cases you always have to set both?

I think a similar API to the following would be more intention revealing and avoid runtime errors:

public ServiceBusProcessor CreateProcessor(otherMandatoryParams..., Func<ProcessMessageEventArgs, Task> messageHandler, Func<ProcessErrorEventArgs> errorHandler, ServiceBusSessionReceiverOptions options = default)

Once you have that signature it becomes clear for me as a user of the API that I always have to specify both. Then it might also become an option to rename the parameter from *EventArgs so something different because really those handlers are not real multicast .NET events.

[danielmarbach]

Thanks for sharing the background info. Learned a ton.

[danielmarbach]

Fair enough. This is my personal feedback from my fiddling around with the new API. That certainly doesn’t invalidate all the previous user studies. Mine is just an opinion I wanted to share. Happy to close after seeing the explanation.

My mind was kind of caught up in finding a solution that would lead me to use it the proper way without having to be told with a runtime exception