none
"Throw Exception" или "return some" RRS feed

  • Вопрос

  • Здравствуйте, беспокоит давно такой вопрос.
    Какой стратегии лучше (правильнее) придерживаться, для возникающих в классе пользовательских и системных исключений:
    • Возвращать "null" или "-1" при возможности и "глушить" (обрабатывать) ошибку прямо в классе.
    • Обрабатывать исключение внутри класса и передавать "выше" месседж об ошибке (не важно как).
    • Передавать исключение "выше".
    • Что-то иное ? Золотая середина ?
    В данный момент все мои простые классы передают системные или пользовательские ошибки выше, но, это, если не ошибаюсь противоречит некоторым правилам ООП, где говорится (не помню как наз. термин) что ошибки не надо тянуть через несколько модулей до обработчика, а стараться локализовывать.
    Сложные же классы выводят в самописную консоль сообщения об ошибке и "глушат" ее внутри себя.
    • Перемещено Tagore Bandlamudi 1 октября 2010 г. 22:57 MSDN Forums consolidation (От:Visual C#)
    12 февраля 2010 г. 21:25

Ответы

Все ответы

  • Все хорошо в меру. Ошибки (Exception) - это исключительные ситуации, которых по идеи быть не должно. Рассмотрим обычный пример, к вам на страницу приходит request и возможно но не обязательно вам должен приходить ID товара, и должен он быть в int, тогда вы будете использовать int.TryParse.
    Другой пример, вы написали страницу, которая только обрабатывает запросы с идентификаторами товаров, по другому быть не должно, тогда вы используете int.Parse или int.TryParse, но в итоге кидаете HttpException, чтобы ASP.NET сам показал нужную ошибку.

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


    [Мой блог], [LinkedIn]
    12 февраля 2010 г. 22:02
  • Есть довольно подробная статья на эту тему в MSDN: Обработка исключений (английская версия чуть поновее).

    • Помечено в качестве ответа I.Vorontsov 16 февраля 2010 г. 7:16
    13 февраля 2010 г. 6:55
  • Я думаю на разных этапах разработки разные стратегии, так к примеру в начальных циклах лутше возбуждать Exception для того чтобы наглядно представлять места возникновения ошибок. В дальнейшем нужно свести к минимуму возможные ситуации при которых возникает ошибка, глушить ошибку не вкоем случаее нельзя, потом сто процентов боком выйдет а найти это ой как не просто.
    13 февраля 2010 г. 11:11
  • Есть мнение, не моё, а Рихтера, исключениями лучше как можно меньше баловаться, если есть возможность, то лучше заменять проверочными блоками if-else, по причинам производительности.
    По поводу того, что нельзя глушить ошибку: не хотел бы я вылавливать в клиентском коде ошибки при чтении базы данных, имхо, тот модуль, который читает базу пусть их и обрабатывает.
    13 февраля 2010 г. 11:49
  • А что подразумевается под "обработать ошибку". Например, модуль доступа к базе данных обнаружил что база вдруг стала совсем недоступна. Как он может такое "обработать"? :) 
    13 февраля 2010 г. 18:11
  • "Есть довольно подробная статья на эту тему в MSDN: Обработка исключений (английская версия чуть поновее)."
    Спасибо, за наводку на очень интересный и полезный раздел!
    13 февраля 2010 г. 20:09