Обеспечение того, чтобы исключения всегда перехватывались

Исключения в C++ не должны быть перехвачены (нет ошибок времени компиляции) вызывающей функцией. Таким образом, это зависит от решения разработчика, следует ли поймать их с помощью try/catch (в отличие от Java).

Есть ли способ гарантировать, что исключения, вызванные всегда перехватываются с помощью try/catch вызывающей функцией?

7 ответов

  1. Нет.

    Смотрите прагматический взгляд на спецификации исключений по причинам, почему нет.

    Единственный способ» помочь » — документировать исключения, которые может создать ваша функция, скажем, как комментарий в файле заголовка, объявляющем ее. Это не принудительно компилятором или чем-то еще. Используйте для этой цели проверки кода.

  2. Или вы можете начать создавать критические исключения. Конечно, исключение нарушения доступа привлечет внимание ваших пользователей.

  3. Вне области вашего вопроса, поэтому я обсуждал не публикацию этого, но в Java есть на самом деле 2 типа исключений, проверенных и непроверенных. Основное различие заключается в том , что, как и вc[++], вам не нужно ловить непроверенное исключение.

    Для хорошей справки попробуйте это

  4. Есть ли способ убедиться, что
    исключения, брошенные всегда пойманы
    использование try / catch by The calling
    функция?

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

  5. У Криса, вероятно, есть лучший чистый ответ на вопрос:

    Однако меня интересует корень вопроса. Если пользователь должен всегда оборачивать вызов в блоке try / catch, должна ли вызываемая пользователем функция действительно создавать исключения в первую очередь?

    Это сложный вопрос, на который трудно ответить без дополнительного контекста относительно рассматриваемой кодовой базы. Снимая с бедра, я думаю, что лучший ответ здесь-обернуть функцию таким образом, чтобы рекомендуемый (если не только, в зависимости от общего стиля исключения кода) публичный интерфейс делал попытку/уловку для пользователя. Если вы просто пытаетесь убедиться, что в коде нет необработанных исключений, модульные тесты и проверка кода, вероятно, являются лучшим решением.

  6. Здесь не следует использовать исключение. Это, очевидно, не исключительный случай, если вам нужно ожидать его везде, где вы используете эту функцию!

    Лучшим решением было бы заставить функцию возвращать экземпляр чего-то подобного. В отладочных сборках (предполагая, что разработчики используют пути кода, которые они только что написали) они получат утверждение, если забудут проверить, прошла ли операция успешно или нет.

    class SearchResult
    {
      private:
        ResultType result_;
        bool succeeded_;
        bool succeessChecked_;
    
      public:
        SearchResult(Result& result, bool succeeded)
          : result_(result)
          , succeeded_(succeeded)
          , successChecked_(false)
        {
        }
    
        ~SearchResult()
        {
          ASSERT(successChecked_);
        }
    
        ResultType& Result() { return result_; }
        bool Succeeded() { successChecked_ = true; return succeeded_; }
    }
    
  7. Когда-то была предпринята попытка добавить спецификации динамических исключений в сигнатуру функции, но поскольку язык не мог обеспечить их точность, впоследствии они были обесценены.

    В C++11 и forward теперь есть спецификатор noexcept .
    Опять же, если подпись помечена, чтобы бросить, по-прежнему не requriement, что это будет обработано вызывающим.


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

    См. раздел: std:: необязательно как часть основ библиотеки.