MethodA вызывает MethodB, который, в свою очередь, вызывает MethodC.

Нет обработки исключений в MethodB или MethodC. Но в MethodA есть обработка исключений.

В MethodC происходит исключение.

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

Что не так с этим?

На мой взгляд, в какой-то момент вызывающая сторона выполнит MethodB или MethodC, и когда в этих методах произойдут исключения, что будет получено от обработки исключений внутри этих методов, которая по сути является просто блоком try / catch / finally, а не просто они пузырились до звонящего?

Оператор или консенсус в отношении обработки исключений - это выброс, когда выполнение не может быть продолжено только из-за этого - исключение. Я понимаю. Но почему бы не поймать исключение дальше вверх по цепочке, вместо того, чтобы блоки try / catch полностью опустились вниз.

Я понимаю, когда вам нужно освободить ресурсы. Это совсем другое дело.

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

Единственные причины, по которым метод должен иметь механизм захвата и отбрасывания:

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

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

Что не так с этим?

Совершенно ничего.

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

«обрабатывает это соответствующим образом» является важной частью. В этом суть структурированной обработки исключений.

Если ваш код может сделать что-то «полезное» с исключением, сделайте это. Если нет, то оставьте в покое.

, , , почему бы не перехватить исключение дальше вверх по цепочке, вместо того, чтобы блоки try / catch полностью опустились.

Это именно то, что вы должны делать. Если вы читаете код, у которого обработчик / обработчик «полностью выключен», то вы, вероятно, читаете какой-то довольно плохой код.

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

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

Вы должны сделать разницу между библиотеками и приложениями.

Библиотеки могут свободно генерировать неисследованные исключения

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

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

Приложения должны всегда в какой-то момент ловить исключения

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

Критическая ошибка ошибка основная логика приложения не может исправить. Например, если в графической игре происходит сбой драйвера графического устройства, приложение не может «изящно» информировать пользователя. В этом случае должен быть записан файл журнала и, если возможно, пользователь должен быть так или иначе проинформирован.

Даже в таком серьезном случае Приложение должно обрабатывать это исключение осмысленным образом. Это может включать в себя написание файла журнала, отправку отчета о сбое и т. Д. У приложения нет причин не реагировать на исключение каким-либо образом.

Что не так с шаблоном, который вы описываете, так это то, что метод А не будет иметь возможности различать три сценария:

1. Метод Б провалился ожидаемым образом.

2. Метод C потерпел неудачу способом, не предусмотренным методом B, но пока метод B выполнял операцию, которую можно было безопасно отменить.

3. Метод C потерпел неудачу способом, не предусмотренным методом B, но в то время как метод B выполнял операцию, которая переводила вещи в предполагаемое временное несогласованное состояние, которое B не смог очистить из-за отказа C.

Единственный способ, которым метод А сможет отличить эти сценарии, будет в том случае, если выбрасываемое из B исключение включает в себя информацию, достаточную для этой цели, или если разматывание стека для метода B приводит к тому, что объект остается в явно недействительном состоянии. К сожалению, большинство структур исключений делают оба шаблона неловкими, заставляя программистов принимать «меньшие злые» дизайнерские решения.