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

[Ghost-chu]

Ecore/src/main/java/cat/nyaa/ecore/EconomyCoreProvider.java

Lines 108 to 109 in 6cf99c5

	depositSystemVault(transactionFee);
	depositPlayer(toVault, amountArrive);

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

[Lori3f6]

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

#2 #5 也是一样。

[Ghost-chu]

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

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

[Lori3f6]

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

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

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

[Ghost-chu]

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

#2 #5 也是一样。

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

[Ghost-chu]

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

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

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

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

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

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

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

[Ghost-chu]

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

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

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

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

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

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

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

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

[Lori3f6]

这里想不出要如何做错误处理，这个操作是分步完成的，如果前一步已经完成而后一步出现异常，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]

这里想不出要如何做错误处理，这个操作是分步完成的，如果前一步已经完成而后一步出现异常，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]

transactionSuccess()

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

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