Имеет смысл ловить исключения в основном (…)?
Я не могу проверить это прямо сейчас, но вы должны иметь возможность декодировать все в новый словарь. Вы должны указать кодировку - я думаю, что UTF-8 является хорошим значением по умолчанию.
enc = 'utf-8'
s = {k.decode(enc), v.decode(enc) for k, v in d.items()}
6 ответов
Если исключение является неперехваченным, то стандарт не определяет, раскручен ли стек. Таким образом на некоторых платформах деструкторы назовут, и на других программа сразу завершится. Ухватывание за верхний уровень гарантирует, что деструкторы всегда называют.
Так, если Вы не работаете под отладчиком, вероятно, мудро поймать все: (...), а также станд.:: исключение. Затем Ваш код приложения может вымыться с RAII даже на критическом исключении. Во многих таких случаях Вы не должны на самом деле мыться, так как ОС сделает это для Вас. Но например Вы могли бы предпочесть разъединяться чисто от удаленных сервисов, если это возможно, и могли бы быть ресурсы, внешние к процессу, такой как названные каналами/взаимными исключениями, которые Вы предпочтете уничтожать вместо утечки.
Перебросок исключения в основном кажется мне ограниченного использования, так как Вы уже потеряли контекст, в который это было первоначально брошено. Я предполагаю, что захват неперехваченного исключения в отладчике является более шумным, чем просто вход отказа к станд.:: cerr, таким образом повторно бросая был бы умным ходом, если существует шанс пропавших без вести входа.
Если Вы хотите, чтобы отладчик захватил неожиданные условия в режиме отладки, которые в режиме выпуска выдают исключение, которое в конечном счете приводит к выходу, то существуют другие способы сделать это, чем отъезд исключения, непойманного так, чтобы отладчик видел его. Например, Вы могли использовать, утверждают макросы. Конечно, это не помогает с неожиданными и непредсказуемыми условиями, как аппаратные исключения при использовании SEH на.NET.
Почему Вы говорите, что исключение было бы распечатано? Это не типичное поведение времени выполнения C++. В лучшем случае можно ожидать, что его тип печатается.
Кроме того, эта программа оставляет состояние "отказа", тогда как исключение могло бы вызвать состояние завершения через аварийное прекращение работы (т.е. с сигналом, обозначенным в коде выхода).
Простой пример ситуации, где стек не раскручивался:
Почему деструктор не называют на исключении?
Список ситуаций, где исключения могут заставить приложение завершать, а не раскручивать стек.
Почему деструктор не называют на исключении?
Если бы исключение не поймано ни на каком уровне и вышло бы основной () затем, реализации позволяют назвать оконечным () скорее, что раскручивание стека (да это поймало меня врасплох также).
В результате я всегда ловлю все исключения в основном ().
int main()
{
try
{
}
catch(std::exception const& e)
{ /* LOG */
// optimally rethrow
}
catch(...) // Catch anything else.
{ /* LOG */
// optimally rethrow
}
}
Помочь с ловлей проблем во время отладки. Получите свои исключения из станд.:: исключение и затем засовывает точку останова в конструктора для станд.:: исключение.
Выгода попытки в основной функции скрывает исключение из отладчика. Я сказал бы, это не хорошо.
С другой стороны, у клиентов, как ожидают, не будет отладчиков, так ловля исключений хороша. Таким образом, это хорошо.
Лично, я ловлю все исключения в основной функции при создании сборки конечных версий, и я не делаю этого при создании настройки отладочного процесса.
Это - глобальный блок выгоды. Это характерно для отображения хорошего, и пользователь понял сообщение ('Внутренняя ошибка') вместо загадочной распечатки исключения. Это может быть не очевидно из определенного блока кода, но это - в целом хорошая идея.
Взгляните на библию C++ т.е. Stroustrup, у него есть пример, который также повторяется в Прикладном программировании на C++. Обоснование:
int main(void)
{
try
{
// your code
}
catch ( /* YourPossibleExceptions i.e. barfs you expect may occur */ )
{
}
catch ( ... ) // unexpected errors, so you can exit gracefully
{
}
}