Question

对不起，我已经更新了这个问题，因为这是一个非常微不足道的问题，我应该强调一下这里的实际问题。

考虑到这一点，唯一的优势就是在日志中或为了具有这样的自定义异常可以使用的可追溯性......

我已将此演示项目放在一起用于grails：https://github.com/vahidhedayati/test-transactions，它是从这里找到的Java示例移植过来的：https://today.java.net/pub/a/today/2006/08/31/jotm-transactions-in-spring-and-hibernate.html

我仍然需要继续努力，但目前我正在努力寻找最佳方法/实践，因为我认为groovy异常的内容并不像它应该的那样干净（看起来比Java看起来要多一些）常规）

example below source code

package com.example.exception

class FlightNotFoundException  extends TravelException {

    public FlightNotFoundException(String message) {
        super(message)
    }

    public FlightNotFoundException(Exception e) {
        super(e.getMessage())
    }

}

这是在groovy中执行Exception类的正确方法吗？

source code

class FlightManagerService {

@Transactional
def reserveFlight(BookingRequest bookingRequest) throws FlightNotFoundException {
...
}

它在这个服务中被使用，并且这些服务中的每一个抛出一个自定义异常，因为我说我可以看到唯一的优势是稍后追踪哪个或什么是异常...但是这一切都非常必要我的意思是简单log.info/error会报告哪个服务失败或者正在抛出异常..

所以不是所有的尝试，我认为我应该真的搞乱，但仍然值得清理只是为了找到更好的做法。回想一下grails trainaction视频我应该删除所有尝试捕获并可能将可抛出的服务操作替换为：

new domainClass(name: "something", value: 'another').save()
        throw new RuntimeException("Issue saving domainClass")

赞赏任何输入

已更新以添加

与约书亚交谈后

@Transactional
 def someThing() { 
    domainInstance.save(failOnError: true, flush: true)
}

应该没有所有花哨的工作就足够了。（将在更新git项目时进行一些实验）

Answer 1

问题是您在非例外情况下使用例外。您正在尝试将它们用于逻辑和业务规则。虽然这很常见，但一般来说，这是一种非常常见的例外滥用。

在最好的情况下，您应该努力使代码不使用流控制的异常。它们只应用于出现异常（例如非预期行为）的情况。

然而，这就是说，如果你继续，你会想确保你不包括堆栈跟踪。 Grails具有巨大的堆栈跟踪，并且在您的异常中填充它们将是一个巨大的性能损失。您可以通过将以下内容添加到自定义例外来避免这样做：

/**
* Don't fill in the stack trace because we want things to be faster.
**/
@Override
public Throwable fillInStackTrace() {
    // do nothing
    return this
}

Grails / Groovy：自定义事务异常

1 个答案: