C # Создание класса проверки ошибок?

Question

Я очень плохо знаком с ООП, и в программе, над которой я работаю, у меня есть класс Utilities, который содержит некоторые общие методы. Должен ли я включить проверку ошибок в класс Utilities или создать новый класс только для проверки ошибок?

Answer 1

У классов "Утилиты" есть отвратительная привычка превращаться в чудовищ - держите код проверки ошибок отдельно.

Answer 2

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

public static class Utility
{
    public static string GetSomeString(string someOtherString)
    {
        try 
        {
            // something
        }
        catch (exception ex) 
        {
            // handle error
        }
        return result;
    }
}

Answer 3

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

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

Answer 4

Существуют различные формы проверки ошибок

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

Модульное тестирование

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

Проверка ошибок .

Я склонен использовать операторы debug.assert по всему магазину для общей проверки ошибок в моих методах и функциях для проверки предположений во время отладки - я склонен использовать их как слабую форму модульного тестирования.

Управление исключениями

Это зависит от области, в которой вы работаете. Исключения в серверной части имеют очень разные сценарии управления, чем интерфейс.

для iinstance WCF имеет интерфейс для исключений. IErrorHandler iirc правильно, но что-либо, связанное с этим, есть только несколько ошибок, которые могут быть вызваны через. В бэкэнде эти сбои могут быть вызваны исключениями, которые являются множеством исключений, связанных с данными на всех уровнях. Вы не хотите, чтобы эти данные попали в интерфейс - но вам нужно записать их. В результате исключения во внешнем интерфейсе - это просто оболочка реальных исключений ... Я хочу сказать, что к тому времени, как вы разобрались, ваш класс утилит будет огромным, и вы захотите начать его разложение на несколько классов. .

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

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

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

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

Этот вид выходит за рамки ООП и затрагивает больше архитектурных вопросов - вам нужно знать, почему вы хотите переместить код в класс утилит, и вам нужно решить, достаточно ли просто поместить его в код ... Я бы предложил это хорошо, но вы должны пойти дальше и думать об управлении ошибками как о собственном решении. Требуется решение в стиле SOA (или, по крайней мере, проект) imo .... это одна из тех вещей, которая не только распространена в приложениях, но и является инвариантной ....

Answer 5

Как насчет использования события Application_Error в файле Global.asax? Это срабатывает, когда в приложении возникает какая-либо необработанная ошибка.

Answer 6

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

Answer 7

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

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