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

Question

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

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

Спасибо

Answer 1

Здесь стоит сделать несколько замечаний:

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

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

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

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

Answer 2

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

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

Answer 3

Бросок исключения:

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

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

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

Answer 4

Это известно как Проектирование по контракту .

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

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

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

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

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

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

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