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:

• Mapping from error condition to error reason
• TranslateException()

@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.