Шаблон проектирования для общего кода обработки ошибок - PullRequest
3 голосов
/ 07 июля 2010

Я ищу некоторые мысли / мнения об архитектуре для слоя кода, который вызывает методы в API.В моем случае вызывающим кодом является C # /. NET, а API является частью неуправляемой устаревшей DLL.Но один и тот же вопрос может применяться во многих разных языках / средах.

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

Часто встречается следующий шаблон, т. Е. Для каждой функции в API:

public void CallMethodX(<params>)
{
    try
    {
        API.MethodX(<params);
        <common code for checking for error conditions in API; convert to exceptions and throw>
        <common code for logging API call>
    {
    catch (SEHException xx)
    {
        <common code for querying API for more info on error and creating new managed exception>
    }
}

Также обратите внимание: различные методы API могут иметь разные подписи.

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

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

  • Перемещение общего кода в служебный класс, который принимает делегат для фактического метода, и внедрение делегата в служебный класс.Затем служебный класс выполняет фактическую обработку исключений и ведение журнала.[Работает нормально, но создание / передача делегата становится немного неуклюжим / уродливым].

  • Используйте шаблон Command.[Работало бы хорошо, но, кажется, очень сложно добавить просто поделиться кодом]

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

1 Ответ

4 голосов
/ 07 июля 2010

Одним из решений, которое вы можете посмотреть, является Аспектно-ориентированное программирование . Это тип проблемы, для которой был разработан AOP. К сожалению, многие языки плохо поддерживают AOP, но если вы заглянете в Google для C # Aspect-Oriented Programming, вы обнаружите, что это выполнимо, см. Aspect-Oriented Programming Using .Net

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...