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

Question

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

public class Enums
{
    public enum Errors
    {
        [Description("This is a test exception")]
        TestError,
        ...
    }
}

Создать пользовательский класс исключений:

public class CustomException : ApplicationException
{
    protected Enums.Errors _customError;
    public CustomException(Enums.Errors customError)
    {
        this._customError = customError;
    }
    public override string Message
    {
        get
        {
            return this._customError!= Enums.Errors.Base ? this.customError.GetDescription() : base.Message;
        }
    }  
}  

Метод GetDescription - это метод расширения enum, который получает описание enum с помощью отражения. Таким образом, я могу выдать исключение как:

throw new customException(enums.Errors.TestError);  

И показать его пользователю в блоке catch как:

Console.WriteLn(ex.Message);  

Я видел этот подход, рекомендованный MVP. Каковы преимущества этого подхода по сравнению с:

• Использование общего исключения: выбросить новое исключение («Сообщение об ошибке»);
• Использование пользовательских исключений: определение пользовательских исключений для любой ситуации. например (WebServiceException класс, AuthenticationException класс и т. Д.)

Вот ссылка на рекомендацию MVP.

Спасибо.

Answer 1

Лично я не думаю, что это хорошая идея.

Вы всегда должны выдавать как можно более конкретные исключения. То же самое касается ловли.

Легко решить, хотим ли мы поймать WebServiceException или AuthenticationException, но с вашим примером Enum мы должны проанализировать строку, чтобы решить, хотим ли мы ее перехватить или нет. Что произойдет, если это сообщение изменится?

Я не думаю, что это имеет какие-либо преимущества. Для каждого типа ошибки вы должны создать нового члена Enum. Почему бы не создать новый класс вместо этого?

Answer 2

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

try 
{
    SomeFunc()
}
catch( CustomException EX)
{
    //This is my error that I know how to fix
    FixThis()
    DoSomeAwesomeStuff()
}
catch( Exception exa)
{
    //Somthing else is wrong 
    WeepLikeBaby();
}

Если я использую сообщение Свойство

try 
{
    SomeFunc()
}
catch( Exception exa)
{
    if(exa.Message == "ErrType 1")
    {
        DoStuff;
    }
    if(exa.Message == "ErrType 2")
    { 
         Die();
     }
}

Использование примера Base enum все еще может сохранить эту возможность. Однако вы даете себе одно место для определения своих сообщений, но это решается различными способами приложениями. Пример enum сделает создание локализованных сообщений довольно простым, так как даст вам возможность самостоятельно определять строки сообщений.

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

public class MyCustomeEx : Exception
{
    int CustID { get; set; }
}

public void Fail()
{ 
    //Awww Customer error
    throw new MyCustomeEx () {CustID = 123}
}

Answer 3

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

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

Answer 4

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

Answer 5

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

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