Hibernate、Spring、@Transactional - 用 try/catch 包围?
我正在使用 Spring 3 和 Hibernate 3.6 开发 Web 应用程序。我对 @Transactional 注解和代码结构有一些疑问。
->当我使用@Transactional(使用Spring进行事务管理)时,调用@Transactional注释的方法时是否必须用try/catch包围它们?
例如,当我得到一个加载、更改和返回一个对象的方法时,我从另一个类调用它:我是否必须用 try/catch 包围该调用?也许出了问题,没有返回对象,数据库连接失败..我不知道。
到目前为止,我认为 @Transactional 关心所有可能发生的异常,并在发生错误时回滚此事务中的每个操作。 但如果发生这种情况,我必须以某种方式通知用户。当我在 try 块中调用事务方法并回滚时,catch 块被激活吗? 我可以告诉用户“确实出了问题”。否则用户可能不会被告知?
或者检查是否有对象返回(if/else)就足够了,那么我不需要try/catch? 我是新人,我想听听其他人如何构建他们的代码。谢谢 :-)
Im working on developing a webapplication with Spring 3 and Hibernate 3.6. Ive got some questions to the @Transactional
Annotation and the structure of the code.
-> When I use @Transactional
(transaction management with Spring), do I have to surround the @Transactional
-annotated methods with try/catch when calling them?
For example, when I got a method which loads, changes and returns then an object and I call it from another class: do I have to surround the call with try/catch? maybe something goes wrong, no object is returned, database connection fails.. I dont know.
until now, I thought @Transactional
cares for all possible occurring exceptions and rolls back every operation in this transaction when an error occurs.
but if it occurs, I must inform the user somehow. when I call the transactional-method in the try-block and it is rolled back, the catch block is activated?
I can tell then the user "something did go wrong". Otherwise the user maybe would not be informed?
Or is it sufficient to check if there is an object returned (if/else), then I dont need try/catch?
Im new and I would like to hear how other structure their code. Thank you :-)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
处理异常 在 Spring 中使用 HandlerExceptionResolvers 和 @ExceptionHandlers 真的很容易。我倾向于专门使用@ExceptionHandler。
您可以使用 @ ExceptionHandler 来处理特定的异常,而不是在 try-catch 块中自行处理。
如果用户想要未找到的资源并且您想要发送 404。
如果存在服务器问题而您想要发送 500,
您还应该严格处理异常。一般来说,你不应该这样做
@ExceptionHandler(Exception.class)
并且我也相信它按顺序工作,所以如果你确实处理一般异常,它应该是类中的最后一个方法。Handling exceptions in Spring is really easy with HandlerExceptionResolvers and @ExceptionHandlers. I tend to use @ExceptionHandler exclusively.
You can use an @ExceptionHandler to handle a specific exception instead of handling it yourself in a try-catch block.
If the user wanted a resource that wasn't found and you want to send a 404.
If there was a Server issue where you'd want to send a 500
You also should narrowly handle the exceptions. In general you shouldn't do
@ExceptionHandler(Exception.class)
and I also believe that it works in order, so if you do handle the general Exception it should be the last method in the class.Spring 使用的关键功能是 异常翻译。
依靠异常转换来生成客户端层理解的异常,并仅在可能的情况下使用 try / catch 。
The Key feature used by Spring is Exception Translation.
rely on exception translation to generate exceptions your client layer understands and use try / catch there only, if possible.
谢谢你回答我。我通读了链接(spring文档),发现了以下内容:
“然而,DAO抛出普通的HibernateException(未经检查,因此不必声明或捕获),这意味着调用者只能将异常视为通常致命的异常- 除非他们想依赖 Hibernate 自己的异常层次结构。
如果不将调用者与实现策略联系起来,就不可能捕获乐观锁定失败等特定原因。对于强烈基于 Hibernate 和/或不需要任何特殊异常处理的应用程序来说,这种权衡可能是可以接受的。”
我的 DAO 基于普通 Hibernate 3 API,因此如果我理解正确,我的 DAO 仅抛出普通 HibernateException。它们不受检查,无需申报或捕获。
如果出现问题,使用 @Transactional 整个操作都会回滚。
为了确保一切按照我的预期工作,我必须将我的 DAO 与我的应用程序代码联系得更紧密。例如,我可以在那里检查是否归还某个对象。 (如果为空 - 否则)
我还可以捕获异常,将其记录下来并通知用户确实出了问题并且他的事务不起作用。
所以在这一点上,我仍然在想 - 取决于交易:
如果我能得到结果,一切都好 - 如果不能,我可以通知用户。
当未指定事务返回结果时,我可以使用 try/catch 来捕获 HibernateException。但此时Transaction还回滚吗?我认为,捕获 HibernateException 可以避免事务回滚。
我还是不知道该怎么办。 :-(
不幸的是,除此之外,我不明白 MVC 异常处理 (@ExceptionHandler) 与此有什么关系。有一个已处理异常的表,但我没有找到 HibernateException。
或者您认为它可以使用:@ExceptionHandler(HibernateException.classs)?您还说您不建议以这种方式处理异常。
thanks for answering me. I read through the link (spring documentation) and I found the following:
"However, the DAO throws plain HibernateException (which is unchecked, so does not have to be declared or caught), which means that callers can only treat exceptions as generally fatal - unless they want to depend on Hibernate's own exception hierarchy.
Catching specific causes such as an optimistic locking failure is not possible without tying the caller to the implementation strategy. This trade off might be acceptable to applications that are strongly Hibernate-based and/or do not need any special exception treatment."
My DAO is based on Plain Hibernate 3 API, so if I understand it correct, my DAO only throws plain HibernateExceptions. They are unchecked and do not have to be declared or caught.
If something goes wrong, with @Transactional the whole operation is rolled back.
To make sure that everything works as I expected it to work, I have to tie my DAO even closer to my application code. There I can check for example if an object is given back or not. (if null - else)
I could also catch the exception, log it and inform the user that something did go wrong and that his transaction did not work.
So at this point, Im still thinking, that - depending on the transaction:
if I can work with a result, everything is ok - if not, I can inform the user.
when the transaction is not specified to give back a result, I can use try/catch for catching a HibernateException. But is the Transaction still rolled back then? I thought, catching an HibernateException avoids Rolling Back of the transaction.
I still do not know what to do. :-(
Beside of this unfortunately I do not understand what MVC Exception Handling (@ExceptionHandler) has to do with this. There was a table of handled exceptions, but I did not find the HibernateException.
Or do you think it will work with this: @ExceptionHandler(HibernateException.classs)? also you said you would not recommend to handle exceptions this way.