C ++: есть ли причины использовать исключения в неисключительных ситуациях

Question

Позвольте мне привести следующий пример: представьте, что у вас есть класс окна, который может иметь дочерние окна.Каждое дочернее окно содержит слабый указатель на родительское окно, каждое окно имеет список общих ptrs для своих дочерних окон.Теперь у меня есть ситуация, что, если дочернее окно разрушено, я не могу знать, разрушено ли оно, потому что родительское окно было закрыто, или потому что само дочернее окно было закрыто.Поэтому решение, которое я придумал, состояло в том, чтобы разыменовать слабый указатель родительских окон в деструкторе дочерних окон в блоке try {} catch {}, чтобы проверить, существует ли родительское окно (псевдокод):

 //we try to retain the parent window here
 try
 {
     //creates a shared pointer from the weak pointer, throws BadReferenceCounterException on fail
     WindowPtr parent = m_parentWindow.retain();

     //check if there is a parent at all, otherwise 0
     if(parent)
     {
         parent->removeChildWindow(this);
     }
  }
  catch(const BadReferenceCounterException & _ec)
  {
     std::cout<<"Catched expected exception, if Parent was closed before me!"<<std::endl;
  }

В этой ситуации я не мог придумать другой способ решить это просто потому, что нет способа узнать контекст, в котором был вызван деструктор.Это глупо, потому что я использую исключение в ожидаемой ситуации?Я знаю, что это не то, что вы хотите делать в критически важном коде, поэтому это не главное.

Спасибо!

Answer 1

Вы, кажется, используете неверную пару общих / слабых указателей. Стандартные (как в C ++ 11, так и в boost) общие / слабые указатели позволяют вам делать это без исключений:

typedef std::shared_ptr<Window> WindowPtr;
typedef std::weak_ptr<Window> WeakWindowPtr;

WeakWindowPtr m_parentWindow;
//...

WindowPtr parent = m_parentWindow.lock();
if (parent)
{
  // here you know parent wasn't destroyed and you can access it via parent
}

Возможно, вы также захотите посмотреть примеры кода, которые я дал в этот ответ на стекопоток