NyaaCat / Ecore

Economy Core
MIT License
0 stars 2 forks source link

[BUG] 没有对 Economy 操作结果进行处理,返回值被忽略 #4

Open Ghost-chu opened 2 years ago

Ghost-chu commented 2 years ago

https://github.com/NyaaCat/Ecore/blob/6cf99c56cbe1c9d4567747097f0eb4dfd6317ea1/src/main/java/cat/nyaa/ecore/EconomyCoreProvider.java#L108-L109

应对 API 调用的结果进行处理,而非直接返回 SUCCESS。

Lori3f6 commented 2 years ago

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

2 #5 也是一样。

Ghost-chu commented 2 years ago

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

记录操作已经成功步骤反着来撤销就好了。

Lori3f6 commented 2 years ago

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

记录操作已经成功步骤反着来撤销就好了。

如果回滚的时候继续出现异常呢?

Ghost-chu commented 2 years ago

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

2 #5 也是一样。

对于 #5,如果你不打算检查异常,那么应该检查一下返回的 boolean。

Ghost-chu commented 2 years ago

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

记录操作已经成功步骤反着来撤销就好了。

如果回滚的时候继续出现异常呢?

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

记录操作已经成功步骤反着来撤销就好了。

如果回滚的时候继续出现异常呢?

那和 https://github.com/NyaaCat/Ecore/issues/4#issuecomment-1047056295 一样,应该检查一下 boolean

Ghost-chu commented 2 years ago

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

记录操作已经成功步骤反着来撤销就好了。

如果回滚的时候继续出现异常呢?

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

记录操作已经成功步骤反着来撤销就好了。

如果回滚的时候继续出现异常呢?

那和 #4 (comment) 一样,应该检查一下 boolean

if(!economy.depositPlayer().transactionSuccess()){
// Rollback
}
Lori3f6 commented 2 years ago

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

记录操作已经成功步骤反着来撤销就好了。

如果回滚的时候继续出现异常呢?

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

记录操作已经成功步骤反着来撤销就好了。

如果回滚的时候继续出现异常呢?

那和 #4 (comment) 一样,应该检查一下 boolean

if(!economy.depositPlayer().transactionSuccess()){
  // Rollback
}

我是想说,在这里检查是否成功意义不大,因为如果是因为经济实现的内部错误而导致调用失败,ECore 没有途径修复的,这个应当是具体的经济实现要处理的事。所以 ECore 只做了逻辑上必须需要的检查,比如扣钱的时候检查是否成功,这个是“功能”需要。

放到具体的情境来讲,如果 //rollback 的部分出现错误,ECore 还要继续处理嘛?要如何处理呢?

Ghost-chu commented 2 years ago

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

记录操作已经成功步骤反着来撤销就好了。

如果回滚的时候继续出现异常呢?

这里想不出要如何做错误处理,这个操作是分步完成的,如果前一步已经完成而后一步出现异常,ECore 只能尝试调用 vault api 提供的接口处理错误,但这些调用依然可能出现错误。我认为在 ECore (vault api 之上) 的层面,没有能安全回滚异常操作的途径,这些错误不应该由 ECore 处理。

记录操作已经成功步骤反着来撤销就好了。

如果回滚的时候继续出现异常呢?

那和 #4 (comment) 一样,应该检查一下 boolean

if(!economy.depositPlayer().transactionSuccess()){
  // Rollback
}

我是想说,在这里检查是否成功意义不大,因为如果是因为经济实现的内部错误而导致调用失败,ECore 没有途径修复的,这个应当是具体的经济实现要处理的事。所以 ECore 只做了逻辑上必须需要的检查,比如扣钱的时候检查是否成功,这个是“功能”需要。

放到具体的情境来讲,如果 //rollback 的部分出现错误,ECore 还要继续处理嘛?要如何处理呢?

rollback部分出现错误,则需要打印日志,记录出错事件。
没有日志如果 Ecore 在后面运行期间出现故障,排障会走不少弯路。

Ghost-chu commented 2 years ago
transactionSuccess()

transactionSuccess() 不是内部错误,Vault的定义是需要通知上层调用者这个失败是经济实现的“预期行为”。

例如Essentials Economy的最大最小限制,如果玩家超过了这个限制,那么这里就会返回一个false,economy.depositPlayer().errorMessage 会附上原因。