дизайн обработки исключений

Question

В моем текущем проекте есть несколько компонентов / библиотек, которые разработаны как адаптеры.
Например, один адаптер инкапсулирует IO-доступ к файловой системе.

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

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

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

Основное приложение имеет три собственных базовых исключения из трех разных сценариев.

Есть несколько адаптеров, которые вызываются из основного приложения.
Теперь каждому адаптеру нужна своя логика сопоставления исключений в основном приложении.
Сопоставление адаптера с типом исключения приложения, дополнительная работа с дополнительной информацией об исключении и т. Д.

Следующий код в настоящее время необходим для сопоставления источника с целевым исключением

        var map = new Dictionary<Type, Type>()
        { typeof(FileAlreadyExistsTechnicalException) } };

        var fileSystemAdapterException = ex as FileSystemAdapterBaseException;
        if (fileSystemAdapterException != null)
        {
            var exception = from mapping in map
                            where mapping.Key.Equals(fileSystemAdapterException.GetType())
                            select mapping.Value;

            var baseTechnicalException = (TechnicalException)Activator.CreateInstance(exception.Single());

            baseTechnicalException.AddPlaceholderEntry(ExceptionPlaceholderConstants.File, fileSystemAdapterException.SourceFile);

            resultException = baseTechnicalException;
        }

        return resultException;

1.) Это хороший дизайн?
2.) Как можно обобщить это отображение?
Сначала я подумал о AutoMapper , но может ли он дать мне возможность поработать над дополнительной информацией?

Answer 1

Ваш первый вопрос был: «Это хороший дизайн?».Трудно ответить на это, не вдаваясь в подробности и не понимая общую картину.Но учитывая все, что вы предоставили, я должен ответить: «Нет».Это не очень хороший дизайн, потому что он невероятно сложный.Мне кажется, что ваша обработка исключений более сложна, чем сама система, для которой она построена.Помни, я просто догадываюсь.Если я разработчик, который должен поддерживать вашу кодовую базу, у меня был бы только один вопрос: «Почему ???».Почему обработка исключений, которая должна быть максимально простой, заключена в собственную парадигму?

У вас есть адаптеры и соответствующие классы исключений, и вы хотите сохранить исходные исключения.Прелесть исключений в том, что они связаны друг с другом (по крайней мере, в мире Java / .NET).В Java у вас есть Exception.getCause (), в .NET - Exception.InnerException.По моему мнению, это все, что вам нужно, и все остальные люди ожидают, чтобы обрабатывать и распространять исключения между различными уровнями абстракции.

Answer 2

Я бы предположил, что вы можете использовать общие исключения.Вы можете определить класс исключения OperationFailedNopException (что означает, что операция потерпела неудачу таким образом, что ничего не делать), а затем извлечь из него универсальный класс-класс OperationFailedNopException , где параметр универсального типа является типом исходного брошенного исключения.Код, который хотел перехватить определенный тип внутреннего исключения, заключенный в определенное внешнее исключение, мог это сделать.Самым значительным предостережением является то, что я не знаю ни одного способа сделать такую ​​вещь инвариантной (так что, если BarException происходит от FooException, брошенное BarException может быть обернуто таким образом, что что-то, ожидающее OperationFailedNopException , может его перехватить.).