Исключение исключения с кодом возврата

Question

Я реализую свою собственную очередь, которая блокируется на .pop(). Эта функция также принимает дополнительный аргумент, который является таймаутом. Так что на данный момент у меня есть такой код:

template <class T> 
class BlockingQueue { 

private: 
    std::queue<T> m_queue; 
    std::mutex m_mutex; 
    std::condition_variable m_condition; 

public: 
    T pop(uint64_t t_millis) { 
     std::unique_lock<std::mutex> lock(m_mutex); 
     auto status = m_condition.wait_for(
      lock, 
      std::chrono::milliseconds(t_millis), 
      [=] { 
       return !m_queue.empty(); 
      } 
     ); 
     if (!status) { 
      throw exceptions::Timeout(); 
     } 
     T next(std::move(m_queue.front())); 
     m_queue.pop(); 
     return next; 
    }; 
} 

где exceptions::Timeout мой обычай исключение. Теперь я думал об этом исключении, бросая с точки зрения производительности. Было бы лучше вернуть какой-то код возврата из этой функции? Как это влияет на производительность?

Также, поскольку .pop уже возвращает что-то, как реализовать дополнительный код возврата? Я полагаю, что потребуется новая структура, которая содержит как T, так и код возврата. Неужели это увеличение сложности действительно стоит того?

Answer 1

Выбросить исключения, если ожидания не были выполнены, вернуть код состояния, когда вы запрашиваете статус.

, например:

/// pops an object from the stack 
/// @returns an object of type T 
/// @pre there is an object on the stack 
/// @exception std::logic_error if precondition not met 
T pop(); 

/// queries how many objects are on the stack 
/// @returns a count of objects on the stack 
std::size_t object_count() const; 

/// Queries the thing for the last transport error 
/// @returns the most recent error or an empty error_code 
std::error_code last_error() const; 

и затем есть маршрут ASIO стиле реактора в сочетании с ИСПОЛНИТЕЛЕМ на основе фьючерсов:

/// Asynchronously wait for an event to be available on the stack. 
/// The handler will be called exactly once. 
/// to cancel the wait, call the cancel() method 
/// @param handler is the handler to call either on error or when 
///  an item is available 
/// @note Handler has the call signature void(const error_code&, T) 
/// 
template<class Handler> 
auto async_pop(Handler handler); 

, который можно было бы назвать так:

queue.async_pop(asio::use_future).then([](auto& f) { 
    try { 
    auto thing = f.get(); 
    // use the thing we just popped 
    } 
    catch(const system_error& e) { 
    // e.code() indicates why the pop failed 
    } 
}); 

Answer 2

Исключением здесь не является. «Тайм-аут» - это, как ожидалось, результат получения элемента из очереди. Без тайм-аут программа по сути эквивалентна проблеме остановки. Предположим, клиент указал, что им нужен неопределенный тайм-аут. Будет ли исключение когда-либо бросать? Как бы вы справиться с таким исключением (если вы все еще живы в этом постапокалиптическом сценарии?)

Вместо этого я нахожу эти два варианта дизайна более логичным (хотя они не единственные):

• Блокировать до тех пор, пока товар не будет доступен. Создайте функцию с именем wait, которая выполняет опрос и возвращает false, если время истекает, или true, когда товар доступен. Остальная часть вашей функции pop() может оставаться неизменной.

• Не блокировать. Вместо того, чтобы вернуть статус:

  • Если операция будет блокировать, возвращение «занято»
  • Если очередь пуста, возвращение «пустое»
  • В противном случае, вы можете «поп» и вернуть «успех»

Поскольку у вас есть семафор, эти варианты кажутся предпочтительнее функцию т.е. не ждет.

Answer 3

Также, поскольку .pop уже возвращает что-то, как бы вы реализовали дополнительный код ? Я полагаю, что потребуется новая структура, которая содержит как T, так и код возврата .

Выполнение этого подхода потребует дополнительных требований к типам, которые могут использоваться с вашим BlockingQueue: они должны быть конструктивными по умолчанию. Этого можно избежать, если pop() возвращает результат через std::unique_ptr (сигнализируя о тайм-ауте с nullptr), но это приведет к заметным накладным расходам.

Я не вижу недостатка в использовании исключений здесь. Если вы измеряете свои таймауты в миллисекундах, то обработка исключения в случае таймаута должна быть незначительной.

Answer 4

Один из способов оповестить об ошибке в подобной ситуации, не выбрасывая исключения, - это использовать что-то вроде шаблона expected<T> от Andrei Alexandrescu.

Он дал nice talk об этом некоторое время назад. Идея состоит в том, что expected<T> либо содержит T, либо содержит объект кода исключения/ошибки, описывающий, почему T не может быть произведен.

Вы можете использовать его реализацию или легко адаптировать идею в своих целях. Например, вы можете легко построить такой класс поверх boost::variant<T, error_code>.

Это еще один стиль обработки ошибок, отличный от целочисленных кодов ошибок C и исключений C++. Использование типа варианта не подразумевает каких-либо дополнительных динамических распределений - такой код может быть эффективным и не требует большой сложности.

Это фактически довольно близко к тому, как обработка ошибок выполняется в Rust идиоматически. c.f. 23