Каковы хорошие способы сбалансировать информативные исключения и чистый код?

С нашим общедоступным SDK мы стремимся давать очень информативные сообщения о том, почему возникает исключение. Например:

if (interfaceInstance == null)
{
     string errMsg = string.Format(
          "Construction of Action Argument: {0}, via the empty constructor worked, but type: {1} could not be cast to type {2}.",
          ParameterInfo.Name,
          ParameterInfo.ParameterType,
          typeof(IParameter)
    );

    throw new InvalidOperationException(errMsg);
}

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

Коллега начал рефакторинг некоторых исключений, бросая что-то вроде этого:

if (interfaceInstance == null)
    throw EmptyConstructor();

...

private Exception EmptyConstructor()
{
    string errMsg = string.Format(
          "Construction of Action Argument: {0}, via the empty constructor worked, but type: {1} could not be cast to type {2}.",
          ParameterInfo.Name,
          ParameterInfo.ParameterType,
          typeof(IParameter)
    );

    return new InvalidOperationException(errMsg);
}

Что облегчает понимание логики кода, но добавляет множество дополнительных методов для обработки ошибок.

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

[Редактировать]

Было бы неплохо иметь плюсы и минусы каждого подхода.

Почему бы не иметь специализированные классы исключений?

if (interfaceInstance == null)
{
    throw new ThisParticularEmptyConstructorException(<maybe a couple parameters>);
}

Это переносит форматирование и детали к самому исключению и оставляет основной класс незагроможденным.

Кажется, что Microsoft (просматривая исходный код .NET) иногда использует строки ресурсов / среды. Например, ParseDecimal:

throw new OverflowException(Environment.GetResourceString("Overflow_Decimal"));

Плюсы:

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

Минусы:

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

Для общедоступного сценария SDK я настоятельно рекомендую использовать Microsoft Code Contracts, поскольку они предоставляют информативные ошибки, статические проверки, а также вы можете создавать документацию для добавления в документы XML и файлы справки, созданные в Sandcastle . Поддерживается во всех платных версиях Visual Studio.

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

Полная документация по кодовым контрактам находится здесь .

Техника, которую я использую, состоит в том, чтобы объединить и передать проверку и использование функции полезности.

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

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

Конечно, есть способы сделать это - строго типизированный язык, дизайн «недопустимые объекты запрещены в любое время», проектирование по контракту и т. Д.

Пример:

internal static class ValidationUtil
{
    internal static void ThrowIfRectNullOrInvalid(int imageWidth, int imageHeight, Rect rect)
    {
        if (rect == null)
        {
            throw new ArgumentNullException("rect");
        }
        if (rect.Right > imageWidth || rect.Bottom > imageHeight || MoonPhase.Now == MoonPhase.Invisible)
        {
            throw new ArgumentException(
                message: "This is uselessly informative",
                paramName: "rect");
        }
    }
}

public class Thing
{
    public void DoSomething(Rect rect)
    {
        ValidationUtil.ThrowIfRectNullOrInvalid(_imageWidth, _imageHeight, rect);
        // rest of your code
    }
}

[примечание] Я скопировал это из вопроса в ответ, если есть комментарии по этому поводу.

Переместите каждое исключение в метод класса, принимая любые аргументы, которые требуют форматирования.

private Exception EmptyConstructor()
{
    string errMsg = string.Format(
          "Construction of Action Argument: {0}, via the empty constructor worked, but type: {1} could not be cast to type {2}.",
          ParameterInfo.Name,
          ParameterInfo.ParameterType,
          typeof(IParameter)
    );

    return new InvalidOperationException(errMsg);
}

Вложите все методы исключения в регион и поместите их в конец класса.

Плюсы:

• Хранит сообщение вне основной логики метода
• Позволяет добавлять логическую информацию к каждому сообщению (вы можете передать аргументы методу)

Минусы:

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

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

public static I CastOrThrow<I,T>(T t, string source)
{
    if (t is I)
        return (I)t;

    string errMsg = string.Format(
          "Failed to complete {0}, because type: {1} could not be cast to type {2}.",
          source,
          typeof(T),
          typeof(I)
        );

    throw new InvalidOperationException(errMsg);
}


/// and then:

var interfaceInstance = SdkHelper.CastTo<IParameter>(passedObject, "Action constructor");

Возможны варианты (подумайте SdkHelper.RequireNotNull()), которые только проверяют требования к входам и бросают, если они терпят неудачу, но в этом примере объединение приведения с получением результата является самодокументированным и компактным.

Если вы работаете в .net 4.5, есть способы заставить компилятор вставить имя текущего метода / файла в качестве параметра метода (см. CallerMemberAttibute ). Но для SDK вы, вероятно, не можете требовать от своих клиентов перехода на 4.5.

Что нам нравится делать для ошибок бизнес-логики (не обязательно ошибок аргументов и т. Д.), Так это иметь единственное перечисление, которое определяет все потенциальные типы ошибок:

/// <summary>
/// This enum is used to identify each business rule uniquely.
/// </summary>
public enum BusinessRuleId {

    /// <summary>
    /// Indicates that a valid body weight value of a patient is missing for dose calculation.
    /// </summary>
    [Display(Name = @"DoseCalculation_PatientBodyWeightMissing")]
    PatientBodyWeightMissingForDoseCalculation = 1,

    /// <summary>
    /// Indicates that a valid body height value of a patient is missing for dose calculation.
    /// </summary>
    [Display(Name = @"DoseCalculation_PatientBodyHeightMissing")]
    PatientBodyHeightMissingForDoseCalculation = 2,

    // ...
}

Эти [Display(Name = "...")]атрибуты определяют ключ в ресурсе файлов , которые будут использоваться для перевода сообщений об ошибках.

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

Проверка бизнес-правил может быть делегирована специализированным классам валидаторов, которые выдают списки нарушенных бизнес-правил.

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

[Serializable]
public class BusinessLogicException : Exception {

    /// <summary>
    /// The Business Rule that was violated.
    /// </summary>
    public BusinessRuleId ViolatedBusinessRule { get; set; }

    /// <summary>
    /// Optional: additional parameters to be used to during generation of the error message.
    /// </summary>
    public string[] MessageParameters { get; set; }

    /// <summary>
    /// This exception indicates that a Business Rule has been violated. 
    /// </summary>
    public BusinessLogicException(BusinessRuleId violatedBusinessRule, params string[] messageParameters) {
        ViolatedBusinessRule = violatedBusinessRule;
        MessageParameters = messageParameters;
    }
}

Вызовы сервисной службы заключены в общий код обработки ошибок, который переводит нарушенное правило Busines в удобочитаемое сообщение об ошибке:

public object TryExecuteServiceAction(Action a) {
    try {
        return a();
    }
    catch (BusinessLogicException bex) {
        _logger.Error(GenerateErrorMessage(bex));
    }
}

public string GenerateErrorMessage(BusinessLogicException bex) {
    var translatedError = bex.ViolatedBusinessRule.ToTranslatedString();
    if (bex.MessageParameters != null) {
        translatedError = string.Format(translatedError, bex.MessageParameters);
    }
    return translatedError;
}

Вот ToTranslatedString()метод расширения, enumкоторый может считывать ключи ресурсов из [Display]атрибутов и использовать их ResourceManagerдля перевода. Значение для соответствующего ключа ресурса может содержать заполнители для string.Format, которые соответствуют предоставленным MessageParameters. Пример записи в файле resx:

<data name="DoseCalculation_PatientBodyWeightMissing" xml:space="preserve">
    <value>The dose can not be calculated because the body weight observation for patient {0} is missing or not up to date.</value>
    <comment>{0} ... Patient name</comment>
</data>

Пример использования:

throw new BusinessLogicException(BusinessRuleId.PatientBodyWeightMissingForDoseCalculation, patient.Name);

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

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

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