Hibernate, Spring, @Transactional - combine with try / catch?

Question

Im working on developing a web application with Spring 3 and Hibernate 3.6. I have questions for @Transactional Annotations and code structure.

-> When I use @Transactional (transaction management using Spring), do I need to surround @Transactional -annotated methods with try / catch when calling them?

For example, when I get a method that loads, modifies, and returns an object, and I call it from another class: do I need to surround the call with try / catch? maybe something went wrong, not a single object returns, the connection to the database fails .. I don’t know.

so far I thought that @Transactional takes care of all the possible exceptions encountered and rolls back every operation in this transaction when an error occurs. but if this happens, I must somehow inform the user about it. when I call a transactional method in a try block and it rolls back, is the catch block activated? Then I can say that "something went wrong." Otherwise, the user may not be informed?

Or is it enough to check if there is an object returned (if / else), then I don't need a try / trick? Im new, and I would like to hear how the different structure of their code is. Thanks: -)

Answer 1

Spring exception handling is very simple with HandlerExceptionResolvers and @ExceptionHandlers. I usually use exclusively @ExceptionHandler.

You can use @ExceptionHandler to handle a specific exception instead of handling it yourself in a try-catch block.

If the user needs a resource that is not found, and you want to send 404.

 @ExceptionHandler(NotFoundException.class) @ResponseStatus(HttpStatus.NOT_FOUND) public void handleNotFoundException(NotFoundException exc) { // log something. } 

If there is a problem with the server in which you want to send 500

 @ExceptionHandler(SomeException.class) public void handleException(SomeException exc, WebRequest request, HttpServletResponse response) { response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, "Sorry dude, my server broke"); } 

You should also use exceptions. In general, you should not do @ExceptionHandler(Exception.class) , and I also think that it works in order, so if you handle the general exception, this should be the last method in the class.

Answer 2

A key feature used by Spring is Exception Translation .

rely on throwing exceptions to throw exceptions that your client level understands, and use try / catch there if possible.

Answer 3

Thanks for answering me. I read the link (spring documentation) and I found the following:

"However, the DAO throws a normal HibernateException (which is not flagged, so it does not need to be declared or caught), which means that callers can only handle exceptions as fatal - if they don’t want to depend on the Hibernate exception hierarchy. Elimination of certain reasons , such as an optimistic blocking failure, is not possible without a caller tied to an implementation strategy.This compromise may be acceptable for applications that are highly dependent on Hibernate and / or do not need special treatment except teachings. "

My DAO is based on the Plain Hibernate 3 API, so if I understand it correctly, my DAO only throws simple HibernateExceptions. They are uncontrollable and should not be billed 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 bind my DAO even closer to my application code. There I can check, for example, if the object is returned or not. (if null is else) I could also catch the exception, register it and tell the user that something went wrong and that his transaction did not work.

So, for now, I still think that - depending on the transaction: if I can work with the result, everything is fine - if not, I can tell the user.

when no transaction is specified to return the result, I can use try / catch to detect a HibernateException. But is the transaction still rolling back? I thought that catching a HibernateException avoids a transaction rollback. I still don’t know what to do .: - (

In addition to this, unfortunately, I do not understand what the MVC Exception Handling (@ExceptionHandler) is related to. There was a table of processed exceptions, but I did not find a HibernateException. Or do you think that it will work with this: @ExceptionHandler (HibernateException.classs)? You also said that you would not recommend handling exceptions this way.