Question

类中有“ addSomething（）”之类的方法。这可以成功或不成功。因此，成功状态可以显示为布尔返回值。但是有时由于多种原因，方法调用可能会失败。 “ false”仅以一般方式显示。有时程序员想知道原因，为什么会失败。为此，提供一个自己的报告类来提供这样的功能有用吗？

public class Report {
    private final boolean success;
    private final String message;

    public Report(boolean success) {
        this.success = success;
        this.message = "empty message";

    }

    public Report(boolean success, String message) {
        this(success);
        this.message = message;
    }

    public boolean wasSuccessful() {
        return success;
    }

    public String getMessage() {
        return message;
    }
}

然后，您可以决定是否要使用“ wasSuccessful（）”获得一般的成功报告，或者是否也要使用“ getMessage（）”记录确切的原因。

Answer 1

为此目的，提供一个提供此类功能的报表类有用吗？

“有用性”是主观的。如果上述方法很好地解决了您的特定问题，那么它当然很有用，并且可能是一个很好的方法。

但是通常，Java中的 failure 通常是通过使用某些麦汁的异常来建模的。

因此，在许多情况下，您只需使用void方法。如：刚返回的方法表示：“一切正常”。否则，如果出现问题，该方法将向您抛出异常。

现在，另一方面，如果您遇到一种方法可能通过或失败并且两种结果都完全可以的情况（例如，如果某个方法检查是否存在 optional 参数），然后确定：您的方法可能会有用。您只需要为每个重要的方法调用添加新的Report对象。然后，调用该方法的任何人都可以创建Report对象，并将它们添加到特定于上下文的ReportCollector中。

但是请注意：我眼中的真实问题：当您考虑以编程方式收集（和使用）此类“进度”信息时，消息字符串会迅速变成一个问题。人们有时使用数字错误ID的充分理由是：能够以编程方式处理此类情况。字符串仅对阅读它们的人有意义。

您的代码对字符串的作用不大。请记住：稍后使用contains("this")或contains("that")确定如何对错误（消息）做出反应，这是一个真正的反模式！

Answer 2

您可以尝试使用类似Either模式的smth。每次使用Either<Report,Error>时，都会得到有效的报告或有错误的对象。

返回状态消息

2 个答案: