Какими исключениями программа никогда не попытается оправиться?

Ответ 1

Руководство по дизайну рамок покрывает это довольно полностью:

Не блокируйте System.Exception или System.SystemException в рамках кода, если вы не собираетесь повторно бросить.

...

Не улавливать System.StackOverflowException.

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

...

Не допускайте явного исключения System.Runtime.InteropServices.SEHException.

Ответ 2

Это теоретический вопрос в каждом конкретном случае, поэтому ответ будет таким же теоретическим. Лучший ответ, который я когда-либо слышал, - Не обрабатывать исключение, если вы не знаете, как его обрабатывать. "Регистрация сообщения и исключение исключения из стека в порядке, потому что вы Фактически что-то сделал (даже если это просто указывает на то, что произошла ошибка). Но, поймав ошибку и не выкидывая ее, может возникнуть скрытые ошибки и сложные сеансы отладки.

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

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

Bottom Line. Независимо от того, обрабатываете ли вы данный тип исключения, действительно зависит от того, знает ли ваш код, что делать, чтобы восстановить, когда возникает тип исключения.

Ответ 3

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

Ответ 4

Это сильно зависит от вашего приложения. Большинство приложений должно, вероятно, показывать сообщение об ошибке и умереть за OutOfMemoryException, но не все - пример представляет собой программу SmartRAM (я думаю, что это имя), которая восстанавливает ОЗУ, пытаясь выделить все больше и больше памяти, пока не получит это исключение - это заставляет Windows отбрасывать весь кеш в ОЗУ, предоставляя вам больше свободной памяти.

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

Ответ 5

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

Java делает это различие явным с их выполнением проверенных исключений; это ошибка, если какое-либо исключение не обрабатывается или не объявляется как потенциальный выход исключения из метода, однако все, что происходит от RuntimeException, неявно согласуется.

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

Хотя это активно применяется только в Java, эта концепция также может быть применена здесь:

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

Ответ 6

Это зависит от того, где в программе происходит исключение.

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