Обработка исключений с учетом потока выполнения

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

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

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

Но вместо того, чтобы возвращать исключение моим пользователям, я бы реализовал коды ошибок. Что-то вроде этого:

class MyRequest
{
    enum RequestErrorCode
    {
        PRICE_OUT_OF_LIMIT,
        VOLUME_OUT_OF_LIMIT,
        ...
        ...
        ...
    };

    bool SetPrice(const int price , RequestErrorCode& ErrorCode_out);

    ...

private:

    external_lib::Request mRequest;


};

bool MyRequest::SetPrice(const int price , RequestErrorCode& ErrorCode_out)
{
    bool bReturn = true;
    try
    {

        bReturn = mRequest.SetPrice(price);
    }
    catch(external_lib::out_of_range_error& e)
    {

        ErrorCode_out = PRICE_OUT_OF_LIMIT;
        bReturn = false;
    }
    return bReturn;
}



      bool SendRequest(UserRequest user_request)
{
    MyRequest my_request;
    MyRequest::RequestErrorCode anErrorCode;
    bool bReturn = my_request.SetPrice(user_request.price, anErrorCode);
    if( false == bReturn)
    {
        //Get the error code and process
        //ex:PRICE_OUT_OF_LIMIT
    }
}

Думаю, в этом случае я решился бы на макрос. Что-то вроде (не проверено, обратная косая черта опущена):

#define SET( ins, setfun, value, msg )                           
  try {
    ins.setfun( value );
  }
  catch( external::error & )  {
    throw my_explanation( msg, value );
  }

и в использовании:

Instrument i;
SET( i, SetExpiry, "01-01-2010", "Invalid expiry date" );
SET( i, SetPeriod, 6, "Period out of range" );

Вы уловили идею.

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

тем не менее, альтернативой предложениям Нила может быть использование boost :: lambda, если вы хотите избежать макросов.

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

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

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