Как я могу уменьшить накладные расходы на отладку из неисключительных исключений

Question

Как я могу уменьшить накладные расходы на отладку из неисключительных исключений

0

Мы используем API, который в значительной степени полагается на исключения для возврата не исключительных результатов. Примером этого (из многих) является то, что для выяснения того, находится ли пользователь в группе людей, мы должны попытаться получить группу и интерпретировать результирующее исключение "без группы". Кроме того, все эти исключения относятся к одному типу.

Мы работаем над большим и сложным проектом с использованием С++ 11, который сильно многопоточен, кроме того, область, над которой мы работаем, связана с сетевой связью, поэтому в точках мы должны одновременно отлаживать несколько экземпляров.

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

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

В настоящее время мы ограничены использованием Visual Studio (или потенциально WinDbg) для отладки.

pjcard 31 янв. 2014, в 17:01

Источник

Теги:

c++

exception

visual-studio-debugging

1 ответ

Ещё вопросы

Arne Mertz · Answer 1 · 2014-01-31T14-16-00.000Z

Выбрасывание исключений в неисключительном случае использования просто неверно. Следующий шаг: каждая функция void, все возвращается, бросая исключения.

Насколько я понимаю, вы используете API третьей стороны, который показывает это странное поведение. Вот что я обычно рассматриваю при работе с "Odd API" любого типа, включая C-API, которые загрязняют все с помощью глупых макросов (да, я смотрю на вас, WinAPI):

Старайтесь избегать частей, которые ведут себя нечетно. В вашем случае: если есть неточные свертки, вы можете позвонить, сделайте это, т.е. вызовите if(hasGroup) getGroup; else... if(hasGroup) getGroup; else... вместо try {getGroup;} catch(X) {...}
Вместо того, чтобы позволить нечетности пульсировать по всему вашему коду, ограничьте его, написав API-интерфейс обертки. В вашем случае: напишите обертку, которая ловит Исключения и переводит их в нормальные значения возврата. Таким образом, ваши кодеры не могут забыть перехватывать обычные исключения (потому что ваша обертка не бросает их), и если вы поместите оболочку в свою собственную библиотеку, вы можете использовать другую политику исключений внутри API-интерфейса обертки. Быстрый пример для вашей проблемы getGroup:
```
//myAPIWrapper.h

namespace myAPIWrapper {

  class Group;

  class User {
  public:
    boost::optional<Group> getGroup();
  };

}


//myAPIWrapper.cpp

#include "OddAPI.h"

namespace myAPIWrapper {

  boost::optional<Group> User::getGroup()
  {
    boost::optional<Group> theGroup;

    try {
      oddAPI::user& oddUser= unwrap(*this);
      oddAPI::group& oddGroup = oddUser.get_group();
      theGroup = wrap(oddGroup);
    }
    catch(oddAPI::exception&) {
    }

    return theGroup;
  }
}
```

К сожалению, альтернативных вызовов нет, весь API использует исключения, и приведенный мною пример иллюстрирует это (т. Е. Единственный способ узнать, что вы не в группе - это вызвать исключение). Мы, конечно, рассмотрели предложение обертки, и, возможно, оно ближе всего к решению, но потребует большого количества стандартного кода и в конечном итоге не устранит риск пропуска исключения. Должен отметить, что это не маленький API небольшой компании, я не могу назвать их, но я подозреваю, что вы можете догадаться.
Другими словами, ваш пример, по сути, то, что мы делаем, попробуйте перехватить исключения на границе между нашим кодом и API, но всегда есть возможность их пропустить, и поэтому мы не можем отключить их. исключения первого шанса и т. д. не помогают нашему рабочему процессу.
«всегда есть возможность их пропустить» звучит так, будто вы часто добавляете новые вызовы в API. Если вы определяете интерфейс со всем, что вам, вероятно, понадобится из этого API, и реализуете его с помощью обертки без исключений, вам нужно будет один раз написать шаблон и выполнить все без риска пропустить исключение. Если вы дополнительно предоставите исчерпывающие модульные тесты для оболочки (что всегда помогает imo), вы можете убедиться, что на самом деле это не исключение. Возможно, один человек должен отвечать за поддержание оболочки, так что другим вообще не нужно беспокоиться об обнаружении исключений.
По сути, это то, что мы должны сделать, но я не вижу преимущества модульного теста. Либо у каждой функции есть try / catch, либо нет. Чтобы в полной мере сказать, что было достаточно безопасно «не беспокоиться о перехвате исключений», вам необходимо знать достаточно о работе API, чтобы гарантировать, что вы смоделировали каждый внутренний путь кода, и даже тогда - с какой целью?
Вам не нужно будет имитировать каждый внутренний путь кода. Дело не в абстракции, инкапсуляции и переносе, а в юнит-тестах. Имитируйте вызовы-оболочки, которые вы собираетесь использовать, чтобы убедиться, что ваша оболочка работает, как задумано, в том числе и не выбрасывает поведение. Вот что такое модульные тесты, независимо от того, используете ли вы сторонний API, пишете класс бизнес-логики или что-то еще.
Вот простой пример того, почему это не так. Я могу «смоделировать» вызов функции StrokeDog (), но вопрос о том, находится ли собака с ударом, не отображается (на самом деле, я даже не знаю, есть ли на самом деле собака, возможно, это просто вывод из какого-то другого состояния). Поэтому, если я последую вашему совету и «проверим» его, когда собака там, я с радостью заключу, что не могу получить никаких исключений. В рабочем коде я обнаруживаю, что при определенных обстоятельствах собака не должна присутствовать, потому что я получаю исключение для «NoDog», о котором я раньше не знал, и мое приложение аварийно завершает работу.