c# - : test-create, try-create、create-catch 哪种设计最可取？

Question

假设有一个创建用户的操作。如果存在指定的电子邮件或用户名，此操作可能会失败。如果它失败了，则需要确切地知道原因。在我看来，有三种方法可以做到这一点，我想知道是否有明显的赢家。

所以，这是一个类用户:

class User
{
    public string Email { get; set; }
    public string UserName { get; set; }
}

创建操作有3种方式:

测试创建

if (UserExists(user)) act on user exists error;
if (UsernameExists(user)) act on username exists error;
CreateUser(user);

UserExists 和 UsernameExists 向数据库服务器发出请求以进行验证。这些调用在 CreateUser 中再次重复，以确保正确使用 API。如果验证失败，我会在这两种情况下抛出 ArgumentOutOfRangeException。因此会影响性能。

尝试创造

enum CreateUserResultCode
{
    Success,
    UserAlreadyExists,
    UsernameAlreadyExists
}

if (!TryCreate(user, out resultCode))
{
    switch(resultCode)
    {
        case UserAlreadyExists: act on user exists error;
        case UsernameAlreadyExists: act on username exists error;
    }
}

此模式只进行一次验证，但我们求助于使用所谓的错误代码，这被认为不是一种好的做法。

创建-捕捉

try
{
    CreateUser(user);
}
catch(UserExistsException)
{
    act on user exists error;
}
catch(UsernameExistsException)
{
    act on username exists error;
}

我在这里不使用错误代码，但我现在必须为每种情况创建一个单独的异常类。这或多或少是应该如何使用异常，但我想知道创建一个单独的异常而不是枚举条目是否值得。

那么，我们有一个明显的赢家还是更多的是品味问题？

Answer 1

So, do we have a clear winner or it's more a matter of taste?

第一个选项有一个根本缺陷 - 如果 CreateUser 依赖于外部资源，那么它永远不会是线程安全的或安全的，并且其他实现可能会在您的测试之间创建。因此，一般来说，我倾向于避免这种“模式”。

至于其他两个选项 - 这实际上取决于故障是否预期发生。如果 CreateUser 预计会在某种程度上正常情况下失败，那么 Try* 模式是我的首选，因为使用异常本质上变成了使用异常来控制流。

如果失败确实是一个异常(exception)情况，那么异常(exception)情况会更容易理解。