Description
In the new azure-messaging-servicebus, the exception class we use is the AmqpException. The user is expected to check its isTransient
and getErrorCondition()
properties to understand the different error scenarios.
In the older azure-servicebus, there were different exception classes to begin with which mapped to a few of the error condition mentioned above with the rest of the error conditions being classified as a "general error". A similar model is used in .Net library Azure.Messaging.ServiceBus, with the difference being that they use a single ServiceBusException class with different values in the reason
field denoting the different error scenarios. The JS library @azure/service-bus
plans to do something similar.
This issue is to request the new azure-messaging-servicebus to follow the same model and have a ServiceBusException
instead of exposing the AmqpException
. Historically, the 50 odd error conditions were not required to be exposed to the user. A smaller set with the rest getting swept under "general error" was good enough. Doing this brings all 4 languages to the same page where we use expose the same set of error scenarios with similar details.
Pointers from the .Net implementation:
@richardpark-msft : after talking with @conniey the implementation of this will be:
- Add ServiceBusException like .NET (basically, rename ServiceBusReceiverException)
- Update
processError
in ServiceBusMessageProcessor to take an ServiceBusReceiverErrorContext rather than just a throwable.- ServiceBusReceiverErrorContext will contain a 'reason' field with the appropriate code.