Обработка ошибок C ++ & mdash; Хорошие источники примера кода?

Практически в каждом фрагменте примера кода везде пропущена обработка ошибок (потому что это «запутывает проблему», к которой обращается пример кода). Мои познания в области программирования основаны главным образом на книгах и веб-сайтах, и вы редко видите там какую-либо обработку ошибок, не говоря уже о хороших вещах.

Где можно найти хорошие примеры кода обработки ошибок C ++? Будут с благодарностью приняты конкретные книги, конкретные проекты с открытым исходным кодом (желательно с файлами и функциями для просмотра) и конкретные веб-страницы или сайты.

29
задан 03.10.2019, 10:55

4 ответа

Книжные Стандарты Кодирования C++ Herb Sutter и Andrei Alexandrescu идут с целой главой по , Обработка ошибок и Исключения включая [1 110]

  • Утверждают подробно для документирования внутренних предположений, и инварианты
  • Устанавливают рациональную политику обработки ошибок и следуют, она строго
  • Различает ошибки и неошибки
  • , Дизайн и безопасный от ошибки при записи код
  • Предпочитают использовать исключения для создания отчетов об ошибках
  • Бросок значением, выгода ссылкой
  • , Отчет, чтобы обработать и перевести ошибки соответственно
  • Избегает спецификаций исключения

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

43
ответ дан 03.10.2019, 10:58
  • 1
    @Sulthan я считал первую строку: " Это не допустимый код Swift, it' s сгенерированный на мухе " но didn' t обдумывают достаточно на второй строке, но Ваш комментарий был просто последней вещью, я должен был понять его правильно так большое спасибо. – Warpzit 11.06.2016, 01:59
  • 2
    +1, из-за исходного именования и сводки маркера. – paercebal 03.10.2019, 10:58
  • 3
    Хороший. I' ve добавил, что к моему к - покупают список. (И I' ll голосуют за этот ответ также, как только я могу голосовать снова.:-)) – Head Geek 03.10.2019, 10:58

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

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

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

В C типичный сценарий обработки ошибок выглядит следующим образом:

int DoA() 
{
 if (location == hellInAHandcart)
  return ERROR;
 else
  RETURN OK;
}

int DoB()
{
  int err = DoA();
  if (err != OK)
     return err;
  else
     return DoSomethingElse1();
}

int DoC()
{
  int err = DoB();
  if (err != OK)
     //Handle My error here in whatever way...
}

В то время как в C ++ ...

void DoA() 
{
 if (location == hellInAHandcart)
  throw Exception("Gone To Hell in a Handcart");
}

void DoB()
{
  DoA();
  DoSomethingElse1();
}

void DoC()
{
  try
  {
    DoB();
  }
  catch (Exception &E)
  {
    // Handle My error here in whatever way...
  }
}
4
ответ дан 03.10.2019, 10:56
  • 1
    @ildjarn: За исключением того, что это isn' t в свободном доступе. – Nicol Bolas 13.10.2011, 12:17
  • 2
    Это, с " в любом way" заполненная часть, является точно видом вещи I' m поиск. – Head Geek 03.10.2019, 10:57

Я предпочитаю обработку исключений, обсужденную в этой статье. Это приводит к чистому коду и избегает явного создания/удаления объектов только к исключениям процессов. http://www.informit.com/articles/article.aspx?p=373339

6
ответ дан 03.10.2019, 10:56
  • 1
    @mjv: последним в свободном доступе черновой стандарт - N3290 является фактическое последнее. – ildjarn 13.10.2011, 12:09
  • 2
    Хорошая статья, спасибо. (I' m из голосов сегодня, I' ll голосуют за этого за несколько часов.) – Head Geek 03.10.2019, 10:57

«Использовать исключения» против «Использовать коды ошибок» никогда не бывает таким четким, как показывают примеры.

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

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

1120 Во-вторых, будьте очень осторожны с иерархиями исключений. Вы можете подумать, что нормально иметь класс Exception, затем извлечь из него NetException, а затем SMTPException для своего класса SMTP. Но если вы не храните общие данные в базовом классе, вам всегда придется перехватывать все типы исключений в этой иерархии. Например. если вы указали причину ошибки SMTP в своем классе SMTPException, вы должны ее уловить - если вы только поймаете типы Exception, у вас не будет доступа к членам SMTPException. Хороший способ решения этой проблемы - иметь строку и член int в базовом классе исключений и использовать их только для производных типов. К сожалению, std::exception предлагает только строку: (

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

Если вы используете исключения, вы должны потрудиться, чтобы заполнить их большим количеством данных, чем было бы с кодом ошибки. В случае ошибок вы должны немедленно обработать их, или они потерялись в коде. За исключением, это может быть поймано на много уровней от того места, где он был брошен - как в примере Родди. Вызывается DoC и получает исключение 2 уровня из DoA. Если вы не укажете ошибку, специфичную для кода в DoA, вы можете Я думаю, что он был сгенерирован из функции DoB. (простой пример, но я видел код, где исключение обрабатывалось на многих уровнях вниз по стеку вызовов. Для отладки было ab st . Это особенно относится к ОО-программам)

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

1124 Исключения хороши, используйте их. Но подумайте о том, что вы делаете, не злоупотребляйте ими и не злоупотребляйте ими. Неправильно используемое исключение хуже, чем отсутствие обработки ошибок вообще (поскольку вы можете получить аварийный дамп и просмотреть необработанное исключение, чтобы найти ошибку за считанные секунды. За исключением исключения, которое съедено и проигнорировано, вы набиты).

За эти годы я обнаружил, что самым большим помощником в отладке является логирование. Пишите логи, пишите много логов.

13
ответ дан 03.10.2019, 10:57

Теги

Похожие вопросы