Подход к функции высокого порядка для исключений в C #

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

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

Не ловите все исключения, параметризуйте тот, который вы хотите:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ProvaException
{
    class Program
    {
        static void Main(string[] args)
        {

            int a = doWithException<int>(divide, 0, typeof(DivideByZeroException), x => 300);
            Console.WriteLine(a);
            Console.ReadKey();
        }

        public static int divide(int b)
        {
            return 10 / b;
        }

        public static T doWithException<T>(Func<T, T> a, T param1, Type exType, Func<Exception, T> handFunction) {
            try
            {
                return a(param1);
            }
            catch(Exception ex) {
                if(exType.Equals(ex.GetType())) {
                     return handFunction(ex);
                }
                else 
                    throw ex;
            }
        }
    }
}

Не очень похоже на С#, но может быть полезно в том же случае (когда вы хотите абстрагироваться от обработки исключения).

Вам нужно написать различную сигнатуру типа для каждого типа функции, потому что С# не поддерживает currying. Виниловая расточка.: D

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

Взгляните на ЭТО и, возможно, немного отбросьте рефлектор ol. Мне кажется, что то же самое делается там, но, возможно, более полным образом... Это кажется очень сильным...

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

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

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

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

Моя первоначальная мысль просто заключается в том, что передача сложных анонимных делегатов вокруг плохо пахнет. Ничего не мешает кому-то сбросить анонимного делегата сложной логикой в ​​методы ErrorHelper. Такая логика становится трудной для тестирования. Я бы предпочел, чтобы логика передавалась только в объекте, который мне кажется более понятным методом. Для меня анонимные делегаты (и лямбды) предназначены для очень простой логической расширяемости, например, для логики сравнения. Механика анонимных делегатов является мощной и может быть использована для других целей, но с большой силой приходит большая ответственность. =)

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

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

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

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

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

bool exceptionHappened = true;
try
{
    alternatePreviewImage.SetSource(fs);
    exceptionHappened = false;
}
finally
{
    if ( exceptionHappened )
    {    
        requiresSpecialPreview = false;
        etc;
    }
}