Бросать новое исключение против записи сообщения обратно пользователю (исключая исключение)

Я вижу много написанного кода, где генерируется исключение, если параметр не в правильной форме или что-то еще. В принципе "бросьте новый...".

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

Спасибо

Ответ 1

Здесь нужно сделать несколько моментов:

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

Ответ 2

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

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

Ответ 3

Выбрасывание исключения:

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

Печать строк - ну, действительно.

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

Ответ 4

Это называется Design by Contract.

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

PS: Важная проблема дизайна по контракту, которая часто забывается, заключается в следующем. Клиент должен иметь возможность знать, выполняет ли он контракт или нет. Так, например, если договор стека заключается в том, что клиент может только pop, когда стек не пуст, должен быть метод isEmpty, чтобы проверить, что и клиенты должны использовать этот метод перед вызовом pop. Вот почему код, который использует Design by Contract, загроможден исключениями, которые тем не менее никогда не бросаются.

Ответ 5

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

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

Вопрос является общим и языковым-агностиком, поэтому ответ не углубляется в детали.

Кстати, в зависимости от языка программирования, проектирования обработки ошибок и количества других факторов подходы могут быть разными. Однако, это хорошая идея, чтобы узнать о различных вариантах:

в С++, в проекте Boost, рекомендации по обработке ошибок говорят:

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

it "should reject a negative initial balance" do
  Account.new(-1).should raise_error(ArgumentError, "Invalid balance: -1")
end