Close() throws exception from the destructor of ProducerClient causing the users to terminate, without an opportunity to catch the exception

[Deepa-Pathak]

In here a call to Close() is made from the destructors, destructors which are noexcept(true) by default.

azure-sdk-for-cpp/sdk/eventhubs/azure-messaging-eventhubs/inc/azure/messaging/eventhubs/producer_client.hpp

Line 101 in 04f2ce0

~ProducerClient() { Close(); }

Close() throws exceptions in various scenarios which leads to user getting terminated whenever that happens.

From here I see two options:

1. Users can hardly do anything if for some reasons it could not be closed, so we can catch and log the exception.
2. Let users call Close themselves to properly handle the scenarios they want.

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @axisc @hmlam @sjkwak.

[vifani]

Are there updates on this bug? This is a problem for the adoption of EventHub in C++

[RickWinter]

Problem Analysis

Summary

The ProducerClient destructor (~ProducerClient()) directly calls Close(), which can throw exceptions. In C++11 and later, destructors are implicitly noexcept(true). If Close() throws during destruction, std::terminate() is called, killing the application without giving the user any chance to handle the exception.

Affected Classes

This bug is not limited to ProducerClient — the same pattern exists in three Event Hubs client classes:

Class	Destructor Location	Call that can throw
ProducerClient	producer_client.hpp L101	Close() — inline in header
ConsumerClient	consumer_client.cpp ~L32	Close({})
PartitionClient	partition_client.cpp	m_receiver.Close()

Root Cause — Exception Sources in Close()

In ProducerClient::Close() and ConsumerClient::Close(), the following operations can throw:

• m_propertiesClient->Close(context) — AMQP network operations
• sender.second.Close(context) / receiver.second.Close(context) — closing AMQP links
• session.second.End(context) — ending AMQP sessions (Rust AMQP backend)
• connection.second.Close(context) — closing AMQP connections (Rust AMQP backend)

Any network error, context cancellation, or AMQP protocol error during these calls will propagate an exception into the noexcept destructor, triggering std::terminate().

For PartitionClient::~PartitionClient(), m_receiver.Close() similarly can throw during AMQP link teardown.

Note: ProcessorPartitionClient::~ProcessorPartitionClient() does not have this bug — its destructor only performs logging and does not call Close().

---

Plan to Fix

Approach

Adopt the issue author's option 1: wrap destructor Close() calls in try/catch blocks and log exceptions at Warning level. Explicit Close() calls by the user continue to propagate exceptions normally, preserving their ability to handle errors.

Changes Required

1. ProducerClient::~ProducerClient() — producer_client.hpp

Move the destructor body out of the header into producer_client.cpp and wrap with try/catch:

ProducerClient::~ProducerClient()
{
  try
  {
    Close();
  }
  catch (const std::exception& ex)
  {
    Log::Stream(Logger::Level::Warning)
        << "Exception in ~ProducerClient: " << ex.what();
  }
  catch (...)
  {
    Log::Stream(Logger::Level::Warning)
        << "Unknown exception in ~ProducerClient.";
  }
}

2. ConsumerClient::~ConsumerClient() — consumer_client.cpp

ConsumerClient::~ConsumerClient()
{
  Log::Stream(Logger::Level::Informational) << "Destroy consumer client.";
  try
  {
    Close({});
  }
  catch (const std::exception& ex)
  {
    Log::Stream(Logger::Level::Warning)
        << "Exception in ~ConsumerClient: " << ex.what();
  }
  catch (...)
  {
    Log::Stream(Logger::Level::Warning)
        << "Unknown exception in ~ConsumerClient.";
  }
}

3. PartitionClient::~PartitionClient() — partition_client.cpp

PartitionClient::~PartitionClient()
{
  Log::Stream(Logger::Level::Verbose) << "~PartitionClient() Close Receiver.";
  try
  {
    m_receiver.Close();
  }
  catch (const std::exception& ex)
  {
    Log::Stream(Logger::Level::Warning)
        << "Exception in ~PartitionClient: " << ex.what();
  }
  catch (...)
  {
    Log::Stream(Logger::Level::Warning)
        << "Unknown exception in ~PartitionClient.";
  }
}

Additional Consideration

Update documentation for Close() on all three classes to recommend users call Close() explicitly before destruction if they need to handle cleanup errors. The destructor should be a safety net, not the primary cleanup path.

---

Plan to Test

Unit Tests

1. Destructor does not terminate when Close() would throw

   • For each of ProducerClient, ConsumerClient, and PartitionClient:
     • Create a client with an invalid/unreachable endpoint so that Close() fails
     • Let the client go out of scope (triggering the destructor)
     • Verify: the test process does not abort/terminate

2. Warning log is emitted on destructor exception

   • Use the Azure SDK test logging listener infrastructure
   • Trigger the same destructor-on-failure scenario
   • Verify: a Warning-level log message containing the exception text is captured

3. Explicit Close() still throws (regression test)

   • Create a client with a bad connection state
   • Call Close() explicitly
   • Verify: an exception is thrown and can be caught by the caller
   • This ensures the fix doesn't suppress errors from the explicit Close() API

4. Double-close is safe

   • Call Close() explicitly, then let the destructor run
   • Verify: no crash, no double-free, no terminate — the destructor's Close() should be a no-op if already closed (or caught gracefully)

Integration / Live Tests

5. Network interruption scenario

   • Establish a working ProducerClient connection to a live Event Hub
   • Simulate connection loss (e.g., firewall rule, test proxy, or cancel the context)
   • Let the client go out of scope
   • Verify: clean process exit, warning log emitted

6. Stress test — rapid create/destroy cycles

   • Create and immediately destroy many ProducerClient / ConsumerClient instances in a loop
   • Verify: no crashes, no resource leaks, no std::terminate calls