.net 实现泛型自定义异常的利弊[已关闭]

3phpmpom 于 2023-03-20 发布在 .NET

关注(0)|答案(6)|浏览(144)

已关闭。此问题为opinion-based。当前不接受答案。
**想要改进此问题吗？**请更新此问题，以便editing this post可以用事实和引文来回答。

3天前关闭。
Improve this 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方法是一个枚举扩展方法，它使用反射获取枚举描述。这样，我可以抛出如下异常：

throw new customException(enums.Errors.TestError);

并在catch块中向用户显示，如下所示：

Console.WriteLn(ex.Message);

我看过一位MVP推荐的这种方法。这种方法与以下方法相比有哪些好处：

使用泛型异常：抛出新异常（“错误消息”）;。
使用自定义异常：定义任何情况下的自定义异常。例如（WebServiceException类、AuthenticationException类等）

Here's the link符合MVP的建议。
谢谢你。

.net

来源：https://stackoverflow.com/questions/6310241/pros-and-cons-of-implementing-a-generic-custom-exception

6条答案

按热度按时间

iyr7buue1#

我个人认为这不是个好主意。
你应该总是抛出尽可能具体的异常，捕捉也是一样。
很容易决定我们是否要捕获WebServiceException或AuthenticationException，但对于Enum示例，我们必须解析一个字符串来决定是否要捕获它。如果消息发生变化，会发生什么情况？
我不认为它有任何好处。对于每一种错误类型，你必须创建一个新的枚举成员。为什么不创建一个新的类呢？

赞(0）回复(0）举报 2023-03-20

lvjbypge2#

定制异常的主要优点是语言支持不同异常类型之间的区别。

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

如果使用message属性

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

使用Base枚举示例仍然可以保留此功能。然而，您给予自己一个位置来定义消息，但应用程序可以通过各种不同的方式解决此问题。枚举示例将使创建本地化消息变得非常简单，因为它将为您提供一种独立定义消息字符串的方法。
另一个优点是你可以添加在你的应用程序中有意义的Customm数据。比如说你有一个客户信息系统，客户ID几乎总是很重要的。如果你只使用消息属性，每个处理程序都必须知道如何在需要的时候解析出这些信息。

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

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

赞(0）回复(0）举报 2023-03-20

6uxekuva3#

选项1我不推荐。你根本不应该抛出System.Exception。你应该总是抛出最具体的异常，以便在你的代码中有合理结构的异常处理。
我在你提出的方法（Errors enum）中看到的主要缺点是，如果不先捕获异常，你就无法决定是否要处理它。

赞(0）回复(0）举报 2023-03-20

qcbq4gxm4#

请参阅我在以下类似的堆栈溢出问题中的（已接受）答案：自定义异常与带有描述性信息的内置异常。它应该有助于提供反对无聊的自定义异常的论据。

赞(0）回复(0）举报 2023-03-20

wkyowqbh5#

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

赞(0）回复(0）举报 2023-03-20

lztngnrs6#

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