Использование bool (возвращаемый тип) для обработки исключений или передачи исключений клиенту?

Question

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

Это прекрасно работает в таких методах, как SaveMyRecord (somerecord); поскольку я передаю значения и не требую ничего возвращаемого, я могу использовать возвращаемый тип bool, чтобы указать, успешно это или нет.

Но потом я подумал, что такие вещи, как GetMyRecord (), на самом деле возвращают тип IQueryable, поэтому я не могу использовать bool, чтобы сказать мне, если это не удалось или нет.

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

Может быть, есть лучший способ, тогда я подумал об использовании параметров OUT, НО это означает, что мне нужно изменить сигнатуру всех методов и добавить дополнительные параметры ..

Может быть, я должен передать исключение обратно КЛИЕНТУ и обработать его там?

Существуют ли какие-либо стандарты или документы для внедрения лучших практик?

Answer 1

Bubble up исключение для КЛИЕНТА и обработать его там. Определенно передайте его в деталях до конца. Большинство лучших практик почти полностью согласны с этим, всегда, наконец, обрабатывают периметр, в данном случае КЛИЕНТА, хотя в других случаях это может быть веб-сервис.

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

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

Answer 2

Вы должны начать читать Руководство по проектированию исключений

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

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

Answer 3

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

Answer 4

Подход, который рекомендуется и считается наилучшей практикой, заключается в использовании исключений. Вы можете (и должны) прочитать Руководство по проектированию платформы (2-е изд.) , в котором есть рекомендации по исключениям и шаблону try-parse.

Есть несколько проблем с использованием кодов возврата (числовых или логических), две самые большие из них:

• Легко игнорируется / игнорируется программистами.
• Не может использоваться во всех ситуациях. Что произойдет, если ваш конструктор потерпит неудачу? Вы не можете явно вернуть значение из конструктора.

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

Answer 5

Один из распространенных шаблонов, который MS, похоже, нравится, - это метод ComputeSomething (), который возвращает int, и метод TryComputingSomething (), который принимает ссылку на целое число и возвращает Boolean. Последний, в случае успеха, сохраняет свои вычисления в переданной переменной и возвращает True; если происходит сбой по «ожидаемой» причине, возвращается False. Обратите внимание, что непредвиденные сбои в любой подпрограмме могут вызвать исключения.

В некоторых случаях может быть полезно использовать другой шаблон и заставить процедуру принять делегат, который будет вызван в случае проблем. Этот делегат может либо вернуть исключение, либо заставить лежащую в основе подпрограмму вернуть значение false, либо, возможно, выполнить другие действия. Обратите внимание, что во время выполнения делегата будет доступна информация, которая будет уничтожена до того, как будет обнаружено любое исключение. Например, если подпрограмма должна считывать строки из файла и преобразовывать символы 20-37 в Date, может быть полезно записать всю строку ввода, если есть ошибка синтаксического анализа. Используя переданный делегат, можно сделать это; без этого было бы намного сложнее.

Answer 6

Это отличный вопрос!

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