实现通用自定义异常的优点和缺点

本文关键字:缺点 自定义异常 实现 | 更新日期: 2023-09-27 17:59:04

实现自定义异常的优点和缺点如下:
创建一个枚举,在其描述中表示错误消息:

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方法是一种使用反射获取枚举描述的枚举扩展方法。这样,我可以抛出异常,比如:

throw new customException(enums.Errors.TestError);  

并在catch块中向用户显示,如:

Console.WriteLn(ex.Message);  

我看过MVP推荐的这种方法。这种方法比以下方法有什么好处:

  • 使用泛型异常:抛出新异常("错误消息")
  • 使用自定义异常:为任何情况定义自定义异常。例如(WebServiceException类、AuthenticationException类等)

这是MVP推荐的链接。

谢谢。

实现通用自定义异常的优点和缺点

就我个人而言,我认为这不是一个好主意。

您应该始终抛出尽可能具体的异常。捕捉也是如此。

我们很容易决定是要捕获WebServiceException还是AuthenticationException,但对于Enum示例,我们必须解析字符串来决定是否要捕获它。如果此消息发生更改,会发生什么情况?

我认为这根本没有任何好处。对于每种错误类型,都必须创建一个新的Enum成员。为什么不创建一个新类呢?

自定义异常的主要优点是语言支持区分不同的异常类型。例如

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();
     }
}

使用基本枚举示例仍然可以保留此功能。然而,您为自己提供了一个定义消息的位置,但应用程序可以通过各种不同的方式解决这个问题。枚举示例将使创建本地化消息变得非常简单,因为它将为您提供一种独立定义消息字符串的方法。

另一个优点是,您可以添加在应用程序中有意义的Cusotm数据。例如,您有一个客户信息系统,客户ID几乎总是很重要的。如果仅使用消息属性,则每个处理程序都必须知道如何在需要时解析出该信息。

public class MyCustomeEx : Exception
{
    int CustID { get; set; }
}
public void Fail()
{ 
    //Awww Customer error
    throw new MyCustomeEx () {CustID = 123}
}

我不推荐选项1。你根本不应该抛出System.Exception。您应该始终抛出适用于您的情况的最具体的异常,以便在代码中进行合理结构化的异常处理。

我在您提出的方法(Errors enum)中看到的主要缺点是,如果不首先捕获异常,就无法决定是否要处理它。对于自定义的例外情况,您可以提前做出决定。

请参阅我对以下类似堆栈溢出问题的(已接受的)回答:自定义异常与内置异常,带有非常描述性的消息。它应该有助于提供反对轻率的自定义例外的论据。

MVP推荐的链接在评论中分享。

在查看了代码和问题之后,我认为这样做的原因是为了限制异常中可能出现的消息。也许有助于本地化异常文本,但在这个例子中还有额外的工作要做。无论如何,这样的方法不应该用于创建不同处理的"异常子类型"。

我不同意批准的评论。修复枚举在大型系统中更有用,而不是每次都创建一个新类,因此使其通用更有意义。此外,每次创建一个新类都会给项目增加负担。