2015-04-14 32 views
0

对不起,我已经更新了这个问题,因为它是一个相当微不足道的问题,我应该在这里突出显示实际问题。Grails/Groovy:自定义事务异常

想着它,唯一的好处将是日志或具有这种自定义异常可能会使用的tracibility的缘故..

我已经把这个演示项目在一起的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异常的内容像它一样干净应该是(比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的trainsaction视频我真的应该删除所有的尝试捕获并可能取代抛出服务行动:

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

任何输入赞赏

更新添加

与约书亚

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

应该没有所有的花哨的工作..(会做一些实验时,并更新git项目)

回答

1

问题是您正在使用例外情况处理非例外情况。您正试图将它们用于逻辑和业务规则。虽然这是非常普遍的,但它是一般非常常见的滥用例外情况。

在最好的情况下,你应该努力使代码不使用异常进行流量控制。它们只能用于出现例外情况(例如不期望的行为)的情况。

但是,这就是说,如果你继续,你会想确保你不包含堆栈跟踪。 Grails有巨大的堆栈痕迹,并且在你的例外情况下将会是一个巨大的性能问题。您可以通过避免添加以下到您的自定义异常这样做:

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

嘿约书亚,感谢..它可能在那里我只是模仿了Java的例子,因此最佳实践的问题。关于服务做一个throwable是好的?也许我应该补充一点呢?@Transactional(Transactional(rollbackFor = FlightNotFoundException.class) – Vahid

+0

默认情况下,Grails中服务抛出的任何事务都会标记事务的回滚(假设有一个事务并且服务方法是通过事务封装的代理来调用的),所以 –

+0

不是真的 - 默认情况下,只有未经检查的异常回滚事务。您可以向@Transactional注释添加属性,以指定哪些检查的异常应该触发回滚和/或不应该检查的异常。因为Groovy通过检查异常来使用技巧来让我们的生活更轻松并不意味着像Spring这样的非Groovy框架可以或将会沿着 –