Недействительный пользователь вводится допустимая причина выдачи исключения?

Недействительный ввод пользователя - это ОЖИДАЕМАЯ ситуация. Вы ожидаете, что это будет происходить так же часто, как и действительный ввод. В таком случае создание исключений может быть слишком большим.

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

Here's how you do it:

On the database side, you throw if you try to create a new user record with a duplicate name. Its an exceptional situation and you can't do anything about it on the database side. You also provide methods for checking the availability of user names.

On the UI side, you allow the user to select a name, then check its availability. Its the responsibility of the UI side to interact with the user and tell them to choose another name. With the ability to check the validity of the name, the UI should never pass in a duplicate name... unless something exceptional has happened.

---

I agree with the book in this case. Your database is the lowest level of your application and shouldn't have too much business logic coded in it (if A happens, then do B, unless C, then D). That doesn't mean you can't provide useful methods within your data layer that you can use to avoid exceptions.

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

http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx http: // msdn. microsoft.com/en-us/magazine/dd419661.aspx[1228 visible

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

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

Мы требуем, чтобы наши объекты домена были действительны всегда. Если делается попытка создать или передать неверные данные, мы выбросим исключение из объекта домена. Но в данном случае это «исключительное обстоятельство». Почему? Логика в том, что плохие данные никогда не должны попадать в домен. Где-то в этом стеке вызовов есть место, где в систему можно было ввести недопустимые данные - будь то просчет, неверные данные из базового источника данных или из-за ввода данных пользователем.

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

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

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

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

Code Complete by Steve McConnell provides a check-list for Defensive Programming that is really good. Under the exceptions topic he includes:

• Does your project have standards (those trump all else)
• Are there alternatives?
• Can you handle it appropriately internally to the method?

My feeling is Defensive Programming should always be managed by the method taking in the data. So, throwing an exception would not be appropriate.

There are always mitigating circumstances, of course.

Я согласен с другими респондентами в том, что ожидается неправильный ввод, и не следует обрабатывать его за исключением. Однако, если вы обнаружите вредоносный ввод (попытка внедрения sql или что-то в этом роде), тогда может потребоваться исключение.

Я слышал и читал, что хорошие методы объектно-ориентированного проектирования не вызывают исключения для пользовательского ввода. Впрочем, эта логика тоже заставляет меня немного почесать в затылке. Подумайте об истории здесь. Вернувшись к программированию на C, я мог бы написать такую ​​функцию, как:

int validateUserInfo(struct info)
{
    //...
}

Вызывающий будет делать что-то вроде:

int errorCode = validateUserInfo(info);
if (errorCode != 0)
    handleError(errorcode);

Насколько я помню, обработка исключений была написана для того, чтобы не возвращать условия ошибки в качестве возвращаемого значения для методов. например, как показано выше. Тем не менее, если я не использую обработку исключений для проверки информации о пользователе, разве я не вернусь к возврату некоторого условия о неверных данных, которое заставляет меня использовать оператор if для проверки недопустимых данных, чтобы изменить мой "успешный" поток выполнения?

Теперь кажется, что мне нужно проверить возвращаемые значения и заключить в try / catch. Метод validateUserInfo в классе C ++ / C # / Java может вызвать исключение для «исключительной ошибки» и вернуть ошибки проверки «неверные данные» в качестве возвращаемого значения или каким-либо другим механизмом. Разве это не усложнение кода ради какого-то «правила объектно-ориентированного подхода»?

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

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