api - getLastErrorCode()是返回错误代码的良好API设计吗？

Question

关于返回错误代码的最佳实践是什么？

有时我们遇到类方法操作不成功的情况，但这并非异常(exception)。如果失败的原因多种多样，那么我们需要一种方法来告诉调用方失败的原因。

例如，我有Actor::equipItem()方法，可将项目装备到RPG角色对象。失败的原因可能是:

字符级别不够高。

角色类无法装备该物品。

字符属性不足(例如强度不足)。

该项目已损坏。

该物品是两只手的武器，角色已经在使用 Dagger 。

等

以我的看法，上述情况并非异常(exception)。我可以通过两种方式实现 Actor::equipItem()。

首先返回int代码，例如0表示成功，而1表示级别不够，2表示错误的字符类，等等。

第二步是返回boolean TRUE或FALSE，并实现Actor::getLastErrorCode()，调用方可以检查它是否需要向用户提供反馈。

就OOP和API设计而言，哪两种是最佳实践？有其他选择吗？是否有最佳实践来处理不是特殊情况的错误代码？

Answer 1

就像我说的那样，我同意cHao的观点，即抛出异常是处理此问题的正确方法。但是，我想评论一下您可能决定如何处理所有这些规则。对于良好的ol'多态性而言，这种情况对于规则引擎而言是完美的情况。 (检查责任链(CoR)设计模式将对此有所帮助。)

您可以在方法中使用一堆if语句。或者，更好的是，让每个if检查成为自己的类，该类实现类似IEquipItemRule的类:

public interface IEquipItemRule
{
    bool CanEquip();
}

然后，您的消费代码可以代替 if语句来处理所有规则，如下所示:

List<IEquipItemRule> equipRules = GetEquipRules();  // This is where the CoR pattern comes in

foreach (IEquipItemRule rule in equipRules)
{
    // Note: Instead of throwing immediately, you could collect all of the
    //       messages and return all of the failure reasons.
    if (!rule.CanEquip()) { throw new AppropriateException(rule.Message); }
}

这样做的好处是可以使用自己的方法进行检查。因此，如果要首先检查此方法是否成功，则使用者可以调用上面的代码。并且当实际方法运行时，它也可以调用此检查代码。

注意:设备规则的示例可能是这样的:

public class CharacterLevelRule : IEquipItemRule
{
    public bool CanEquip()
    {
        if (characterLevel <= necessaryLevel) { return false; }
        return true;
    }
}