Каковы плюсы и минусы обработки ошибок в начале и в конце метода

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

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

Обработка в начале:

public String GenerateSomeStringData(String data, int value)
{
    if (data == null)
        throw new ArgumentNullException("data");

    if (value <= 0)
        throw new ArgumentException("value must be greater than zero");

    int dataValue;
    if (!int.TryParse(data, out dataValue))
        throw new InvalidOperationException("data does not contain an integer");

    return dataValue * 4 + value / 12;
}

Обработка в конце: (тот же пример)

public String GenerateSomeStringData(String data, int value)
{
    if (data != null)
    {
        if (value > 0) 
        {
            int dataValue;
            if (int.TryParse(data, out dataValue))
            {
                return dataValue * 4 + value / 12;
            }
            else 
                throw new InvalidOperationException("data does not contain an integer");
        }
        else 
            throw new ArgumentException("value must be greater than zero");
    }
    else 
        throw new ArgumentNullException("data");
}

Какие критерии вы используете при решении, как подойти к этому? Читабельность, ремонтопригодность, краткость?

Источник

4 ответа

Решение

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

Это имеет следующие преимущества:

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

  • Четкое разделение проблем между обработкой ошибок и логикой выполнения
    в вашем методе: логика проверки не "прилипает" к логике выполнения

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

Источник

Как уже упоминалось, я проверял бы правильность ввода перед выполнением какой-либо основной логики метода. Это не только логично, но и уменьшает уровни отступа в вашем коде и гарантирует, что у вас не будет длинных операторов if {}, которые вы не увидите на одном экране

Источник

Первый способ намного лучше.

Это поможет вам сохранить все ваши проверки в одном месте. Вы могли бы даже написать универсальную функцию для обработки этого типа проверок.

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

Если ваш код охватывает чуть больше, будет сложно отследить закрывающие скобки в циклах if.

Источник

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

Источник
Другие вопросы по тегам