问显示异常

EN

为什么异常有名称/类型？

因为我们有代码构造来根据异常类型捕获异常。

为什么异常具有自定义属性？

这样，捕获异常的代码就有了处理以一致格式传递给它的异常所需的所有信息。

为什么异常有消息？

可能是因为异常“从错误中”“增长”出来，并且它们曾经有代码和消息。

用户是否应该看到异常？

不是整件事，不是。

它们是一个巨大的、可怕的屏幕，充斥着用户根本不感兴趣的技术“胡言乱语”。

用户是否应该看到异常消息？

也许，但是，正如你非常正确地说的那样，你在翻译和信息需要生成的地方遇到了各种各样的麻烦。

捕捉并即时翻译消息(您的“案例”语句)是另一种选择，但请记住，您不能仅仅在消息中寻找确切的单词，因为，错误地引用了伦纳德McCoy的话：

我了解开发人员，他们喜欢改变事物。

当然，如果没有合适的翻译/映射，您的"case“语句应该始终具有逐字传递给定消息的次要位置，或者附加一个”我不认得这个消息！“绰号。这样你就不会“错过”任何东西。

选项1混淆了应用程序逻辑和UI，正如您已经注意到的。它还会破坏应用程序的国际化，因为消息是硬编码到应用程序代码中的。

选项2只是将问题转移到应用程序逻辑的另一个部分。

如果需要向用户显示异常，而不是所有异常都显示出来，那么将异常传递到UI层。然后，它可以查看异常类型，以及在异常中传递的任何数据，然后确定要显示给用户的消息。使用查找表(而不是开关语句)来处理所有不同的异常类型可能会更好。

请看维克托·伦蒂亚的以下文章：https://victorrentea.ro/blog/presenting-exceptions-to-users/

它关注于Java，但是这种方法也适用于C#。

他们的想法是：

为要以不同方式显示的每个错误条件定义一个带有值的枚举：

public enum ErrorCode { General, BadConfig, ... }

当您这样做时，考虑一下用户可以对错误做些什么。如果用户不能对此做任何事情，只需使用General错误代码，这将最终显示如下：“哎呀，出了问题，对不起。请稍后再试。”

接下来，定义一个自定义应用程序异常，其中包含这样的错误代码：

public class AppException : Exception
{
    public ErrorCode errorCode {get;}

    public AppException(ErrorCode errorCode)
    {
        this.errorCode = errorCode;
    }
}

然后，在主应用程序中捕获异常。如果是AppException，则提取ErrorCode并调用一些逻辑将其转换为消息。消息也可以来自属性文件。如果是其他异常，则以与带有AppException错误代码的General一样的方式显示它。

所以总的来说，这是在你的两个选择之间，有一些好处。

业务逻辑不关心错误消息，只关心错误条件。但是，对于每个错误条件，您不需要一个自定义异常类型，只需要一个枚举值。

在捕获异常时，您只关心两种情况：AppException和所有其他Exception。将错误代码转换为消息可以委托给另一个方法或另一个类。