I wanted to know if there was a way to have setters throw errors in Swift. I assume this would solve my problem but the fact that I couldn't find a way to do it makes me wonder if I've structured my code the right way. Here's the problem I'm trying to solve:

我想知道是否有一种方法可以让二传手在SWIFT中抛出错误。我认为这会解决我的问题，但我找不到方法这样做的事实让我怀疑我是否以正确的方式构建了代码。以下是我正在努力解决的问题：

I have a struct called Account which users can edit from their end

我有一个名为Account的结构，用户可以从他们的终端编辑它

struct Account {
    var strikes: Int = 0
    
    private var _monetizationLevel: Int = 1
    
    var monetizationLevel: Int {
        get { _monetizationLevel }
        set {
            guard strikes == 0 else { print("Please resolve copyright strike before adjusting moentization level"); return }
            guard newValue <= _monetizationLevel else { print("Monetization level can only be increased by a server admin"); return }
            _monetizationLevel = newValue
        }
    }
}

Using Swift's inbuilt support for setters felt like a natural way to go about editing characteristics of your account. eg. myAccount.name = "newName123", myAccount.monetizationLevel -= 4 (or whatever)

使用SWIFT内置的对setter的支持，感觉像是编辑帐户特征的一种自然方式。例如。MyAccount t.name=“newName123”，myAccount t.moneizationLevel-=4(或其他名称)

However, since monetizationLevel has certain restrictions on how much of it you can edit I assumed throwing errors would be a fitting solution to it (since simply printing warnings felts very weak). Unfortunately, I wasn't able to find a way to have the setter throw an error. I thought about using throwing functions like setMonetizationLevel(to: Int) but using function setters seemed really silly considering Swift has inbuilt ones specifically to eliminate the awkwardness of using function setters. I would prefer a Swift-y solution that preserves the naturalness of myAccount.name = "blah", myAccount.monetizationLevel -= 5, etc. just for consistency sake.

然而，由于monetizationLevel对您可以编辑的内容有一定的限制，我认为抛出错误将是一个合适的解决方案（因为简单地打印警告感觉非常弱）。不幸的是，我无法找到一种方法让setter抛出错误。我考虑过使用像setMonetizationLevel（to：Int）这样的抛出函数，但是考虑到Swift已经内置了专门用来消除使用函数setter的尴尬，使用函数setter似乎真的很愚蠢。我更喜欢Swift-y解决方案，它保留了myAccount.name =“blah”，myAccount.monetizationLevel -= 5等的自然性，只是为了保持一致性。

On the other hand, if there's no way to achieve this without using function setters what would be a better way to restructure my Account struct? How would you guys go about this?

另一方面，如果不使用函数设置器就无法实现这一点，那么重构我的帐户结构的更好方法是什么？你们会怎么做呢？

This has already been discussed in comments, no setters cannot throw - the contract of a setter is simple - the property value is set. There is no way for the compiler to know that account.monetizationLevel can throw.

这已经在评论中讨论过了，没有设置器不能抛出-设置器的契约很简单-属性值被设置。编译器没有办法知道Account。moneizationLevel可以抛出。

What you need to consider is where you want to implement you business logic. It looks like you are trying to implement business logic in this struct, and you say "The inconsistency (of mixing setters and functions) would really bother me :/"

您需要考虑的是要在哪里实现业务逻辑。看起来您正在尝试在这个结构中实现业务逻辑，并且您说“(混合setter和函数)的不一致会让我非常困扰：/”

If you are going to implement business logic in this struct, then you probably shouldn't use setters at all. Presumably there is some business logic around strikes - ie they should be >=0

如果要在此结构中实现业务逻辑，则可能根本不应该使用setter。大概有一些关于罢工的商业逻辑--即它们应该>=0

Maybe recording a strike should also reduce monetisation?

或许记录一次罢工也应该减少货币化？

Also, your logic says that only admins can increase monetisation, but there is no way for the setter to know if the caller is an admin - you can provide this to a function.

此外，您的逻辑表明，只有管理员才能增加货币化，但setter无法知道调用者是否为管理员--您可以将其提供给函数。

Exposing properties as read-only and using functions for setting is possibly a better approach. I think it results in an API that is easier to understand and which separates operations from implementation.

将属性公开为只读并使用函数进行设置可能是更好的方法。我认为它会导致一个更容易理解的API，并且将操作与实现分离。

For example:

例如：

enum AccountException: Error {
    case BadCopyrightStanding
    case NotPermitted
}

struct Account {
    private (set) var strikes: Int
    private (set) var monetizationLevel: Int
    var hasStrikes: Bool {
       return strikes != 0
    }
    mutating func recordStrike() {
        self.strikes+=1
        self.monetizationLevel = 1
    }
    
    mutating func clearStrike() {
        self.strikes = max(self.strikes-1,0)
    }
    
    mutating func clearStrikes() {
        self.strikes = 0
    }
    
    mutating func setMonitizationLevel(_ level:Int, isAdmin: Bool) throws {
        guard self.strikes == 0 else {
            throw AccountException.BadCopyrightStanding
        }
        guard isAdmin || level <= self.monitizationLevel else {
            throw AccountException.NotPermitted
        }

        self.monetizationLevel = level
    }
}

Or, if you are implementing business logic elsewhere, then this should just be a "dumb struct" and it should not enforce the relationship between strikes and monetisation.

或者，如果你在其他地方实现业务逻辑，那么这应该只是一个“愚蠢的结构”，它不应该强制罢工和货币化之间的关系。