"ExceptionHandling" Net4. Миграция в .NET. Ищу мнений и советов

Тема очень большая. Постараюсь вкратце о проблеме и возможных решениях.
Но так как у меня сохраняются сомнения "а нужно ли это вообще делать?", то нахожусь в подвешенном состоянии.

Наследние
Был энтерпрайз проект на .Net48. Уже мигрирован в .NET8.
Но остаётся в проекте некоторое легаси, которое хочется скорее убрать. Но так как "нельзя просто взять и убрать", то требуется определить её ценность, функционал и возможную замену. Так случилось с зависимостью от целого набора библиотек Microsoft.Practices.EnterpriseLibrary, которые во стародавние времена поднимали уровень технологичности кода на вероятный уровень. Но чем больше человечество изобретало всякие новые Cшарпы, тем ненужнее становились эти библиотеки. Но есть что-то что стало "частью корабля". И этим стали Logger и ExceptionHandling

ExceptionHandling
Суть этой библиотеки - перехват исключений, и после анализа, с использованием настраиваемой конфигурации, выполнение сценария.
Пример конфига: App.config
Сценарий можно описать примерно так:
- есть исключение
- на него может быть несколько основных реакций: проброс дальше (rethrown), выброс нового исключения, подавление исключения, но с извещением о том что рекомендуется это сделать (NotifyRethrow) и полное игнорирование
- к реакции делается привязка exceptionhandlers - собственно вся основная и сложная логика.
Это привязка классов и собственно выполнение сценариев. Например, логирования (это к вопросу о том почему часть корабля не только этот модуль, а ещё и логгер). Где указывается класс логгера, настройки формата, категорий и всякая доп.информация. Для нового исключения тоже свои классы. Ну и т.п. и т.д.

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

Сначала я быстро реализовал основу модуля.
Но чем больше изучал код, тем больше осознавал что функционал у него намного выше. А то что я сделал - не замена. По сути я реализовал только реакцию на определённые исключения. А в идеале нужно заморочаться за парсинг полного assembly имени (с версиями и токенами). А так же проверять на цепочку наследований нашего исключения, чтобы сработало и на указании только базового. Ну и т.д.

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

И вот наверное вопрос: кто-то использует что-то подобное?
Возможно сам фильтрует исключения и делает нужную реакцию, или использует другие библиотеки (но я не видел ничего подобного).
Стоит ли и мне дальше это поддерживать? Если это убрать, то у меня сломаются примерно два правила, связанные с ошибками ORM, которые подавляют ошибки, логируют и прокидывают исключение в специфические классы. Теоритически их и придётся реализовать специально.

0

HF, я впервые про такую байду слышу. Лично я бы постарался выбросить эту штуку. По тому, что ты описал, выходит, что оно не сильно широко в проекте используется и это можно заменить на обработку в мидлварях. Может быть, по-этапно, если за раз затруднительно будет.

1

А какие тут еще советы давать, обработка исключений и логирование - настолько обычные вещи (cross-cutting concerns), что частенько воспринимаются как "обeзьянья" работа для опытных разработчиков, точно так же как CRUD в приложениях, мало мальски работающих с данными.
У любого кода есть свой жизненный цикл - у того кода, конфиг которого вы показали, он явно закончился.
Просто меняйте и все. Гляньте в сторону IExceptionHandler + ProblemDetails. ProblemDetails описано в каком-то rfc, насколько я помню, то есть все по канонам.

1

Всем спасибо. Убедили.
Надеялся ещё услышать начальника транспортного цеха sau. Он то с древними технологиями вроде бы много работал и... боюсь предположить что и сейчас тоже.

0

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

0

Сообщение от HF Он то с древними технологиями вроде бы много работал и...

Дело не в древних технологиях, а в том, какой конкретно функционал это legacy реализует в вашем проекте, и заменить его на современное API. Либа, теоретически, может уметь сильно больше, чем нужно вам.

0

Сообщение от IamRain и заменить его на современное API. Либа, теоретически, может уметь сильно больше, чем нужно вам.

Вот, это два из описанных вопросов.
- я не видел ничего подобного
- и да, оно вроде бы очень простое по сути, но делает действительно много. Видимо сделали универсальный движок, который можно поднастроить как ты хочешь (указывать свои хендлеры с совершенно разной логикой).
И именно в п.2 я больше всего сомневался. "Люди старались, придумывали, писали, а я просто взял и выкинул. А вдруг полезное?"

Но я тоже, как Usaga придерживаюсь подобных подходов. И уж лучше я её уберу и потом что-то верну (если вдруг всплывёт этот исключительный случай, ради которого вся эта либа и жила в проекте).

0

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

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

Добавлено через 8 минут

Сообщение от HF боюсь предположить что и сейчас тоже.

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


Вот и Microsoft.Practices.EnterpriseLibrary, ну хорошо же , все там есть , другое дело что может быть на современные рельсы не встанет , и трендам не следует , увы - надо погуглить че там мелкие сами по этому поводу пишут.

1

Сообщение от sau А по поводу своих велосипедов . это как раз усложняет сопровождение . одно дело возложить это труд на других разрабов

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

Но в данном случае ТС описал проблему так, будто бы заместить эту зависимость будет не сильно проблематично. Я бы выбрал именно такое решение (именно в данном случае).

1

Продолжение истории. Решил тоже поделиться, так как это и для меня было приятной неожиданностью. Да ещё и подтвердило полезность тестирования (спойлер).

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

Решил я обложить этот сервис тестами (на самом деле мне пришлось это делать, так как я и тесты мигрирую, а этот сервис попал в список). И случилось действительно предсказуемое - после перечисления всех "тест кейсов" стал абсолютно понятен смысл этого сервиса. Да ещё выяснилось что в одном случае это не работало, так как было завязано на Mssql (а уже в наличии PostgreSQL).
В итоге стало понятно как его можно переписать и ничего не сломать.

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

Слава тестам!

3