Использование статического метода класса сообщений, выполняющего действие для переноса Try / Catch

Question

У меня есть объект Result, который позволяет передавать список сообщений о событиях, и я могу проверить, было ли действие успешным или нет.

Я понял, что написал этот код во многих местах

Result result;

try
{
    //Do Something 
    ...

    //New result is automatically a success for not having any errors in it
    result = new Result(); 
}
catch (Exception exception)
{
    //Extension method that returns a Result from the exception
    result = exception.ToResult();
}

if(result.Success) ....

Я собираюсь заменить это использование на

.

public static Result CatchException(Action action)
{
    try
    {
        action();
        return new Result();
    }
    catch (Exception exception)
    {
        return exception.ToResult();
    }
}

А затем используйте его как

var result = Result.CatchException(() => _model.Save(something));

Кто-нибудь чувствует, что с этим что-то не так, или я обмениваю возможность повторного использования на мрак?

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

Answer 1

Не думаю, что с функциональным подходом и передачей лямбды что-то не так. Это совершенно верно.

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

При этом, если вы действительно хотите это сделать, у меня есть пара советов для вас:

1) Я бы сделал статичный, неизменный результат для успеха и просто сделал бы:

result = result.Success;

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

2) Я бы, вероятно, избежал метода расширения и сделал бы:

result = new Result(exception);

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

Answer 2

Вы не должны ловить Exception, как это. Вы должны ловить только известные типы исключений, которые вы знаете, как обрабатывать.

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

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

---

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

Answer 3

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

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