服务层应该返回什么类型的结果？

发布于 2024-10-09 13:32:10 字数 852 浏览 0 评论 0原文

举例来说，假设我有一个创建帖子的 PostsService：

public class PostsService : IPostsService
{
    public bool Create(Post post)
    {
        if(!this.Validate(post))
        {
            return false;
        }

        try
        {
            this.repository.Add(post);
            this.repository.Save();
        }
        catch(Exception e)
        {
            return false;
        }
    }
}

这样做的问题是，如果在存储库操作期间引发异常，该异常就会被吞掉。 Create() 返回 false，消费者只知道 Post 未添加，但不知道为什么。

相反，我想到了一个 ServiceResult 类：

public class ServiceResult
{
    public bool Success { get; private set; }
    public Exception Exception { get; private set; }
}

这是一个好的设计吗？或者我是否需要向消费者报告这些错误？说“添加帖子时发生错误”就足够了吗？然后记录服务内部的异常？

任何其他建议表示赞赏。

原文

Say, for example, that I have a PostsService that creates a post:

public class PostsService : IPostsService
{
    public bool Create(Post post)
    {
        if(!this.Validate(post))
        {
            return false;
        }

        try
        {
            this.repository.Add(post);
            this.repository.Save();
        }
        catch(Exception e)
        {
            return false;
        }
    }
}

The problem with this is that if an exception is thrown during the repository actions, it's swallowed. Create() returns false and all that the consumer knows is that the Post wasn't added, but doesn't know why.

Instead, I was think of having a ServiceResult class:

public class ServiceResult
{
    public bool Success { get; private set; }
    public Exception Exception { get; private set; }
}

Would this be a good design? Or do I even need to report these errors to the consumer? Is it sufficient to say "An error occurred while adding the post." and then log the exception inside of the service?

Any other suggestions are appreciated.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

泪眸﹌ 2024-10-16 13:32:10

我认为这取决于原因的范围。在我看来，一些失败原因不应该引起消费者的关注，这些应该记录在服务中。另一方面，在某些情况下，应该告知消费者这些原因，因此除了记录它们之外，您还应该以某种方式指出错误的原因。

例如，假设用户注册服务的一个非常常见的用例。您很可能有一个唯一的属性来标识用户（用户名、电子邮件等）。这种唯一性必须由服务强制执行（也可能在数据库级别）。现在，如果消费者尝试注册用户并且由于违反约束而失败，则应通知消费者此原因（以便它可以尝试其他用户句柄）。大多数情况下，失败的验证都属于同一场景。

另一方面，如果存在某种内部数据库问题，则不应向消费者告知详细信息（因为这是服务的专有责任；而且消费者无论如何也无能为力）。

考虑到这一点，我想说在很多情况下返回布尔值是不够的。因此，拥有某种 ServiceResult 类型听起来并不是一个坏主意。不过，我不确定是否会包含 Exception 。但也许您可以创建某种特定于您的服务的 ServiceExpection。有时错误代码也适合这种情况。

回复收藏 0 原文

坦然微笑 2024-10-16 13:32:10

捕获所有异常确实是个坏主意。你只能抓住那些你可以合理处理的东西。你无法处理所有异常，那么为什么要捕获它呢？为了防止堆栈跟踪？

如果你不希望你的用户看到可怕的堆栈跟踪，我明白，但你确实希望它死掉并且死得很可怕，这样某些东西就不会被损坏。

假设服务抛出了 OutOfMemoryException，您只是捕获了它，并且不知道您的应用程序是否像筛子一样泄漏内存或不正确地分配大对象。

这是一件坏事。

如果您不希望用户看到出了什么问题，那么您应该将捕获更改为：

catch (Exception e)
{
    //send it to yourself, log it. Just don't swallow it.
    LogErrorAndEmailDevTeam(e); 
    throw new SaveFailedException("We're sorry. \n" + 
    "It's not your fault, but something bad happened.\n\n" + 
    "We've been notified and will fix it as soon as possible.");
}

但更好的是让应用程序惨死，而不是捕获该异常，以便在出现问题时快速知道。

您不希望应用程序继续处于损坏状态，但这正是catch (Exception) 的作用。你真的确定你能处理抛出的任何东西吗？

It's a really bad idea to catch all exceptions. You only catch that which you can reasonably handle. You can't handle all exceptions, so why are you catching it? To prevent a stack trace?

If you don't want your users to see a horrible stack trace, I get that, but you do want it to die and die horribly so that something isn't corrupted.

Let's say that service threw an OutOfMemoryException, you just caught it, and won't know whether or not your application is leaking memory like a sieve or is improperly allocating large objects.

That's a bad thing.

If you don't want your user to see what was wrong, then you should change your catch to say:

catch (Exception e)
{
    //send it to yourself, log it. Just don't swallow it.
    LogErrorAndEmailDevTeam(e); 
    throw new SaveFailedException("We're sorry. \n" + 
    "It's not your fault, but something bad happened.\n\n" + 
    "We've been notified and will fix it as soon as possible.");
}

But even better would be to let the application die a horrible death instead of catching that exception so that you know quickly when something goes wrong.

You don't want your application to continue in a corrupted state, but that's what catch (Exception) does. Are you really sure you can handle whatever is thrown?

回复收藏 0 原文