I have below piece of code in my project. An exception is thrown at line # 4 still my product details are saved. I am having hard time to understand why does it save product details even after throwing the exception
I am also trying to understand if the exception thrown at line #4 is a checked or unchecked exception ? If i am throwing "throw new Exception("Details don't match")" it is a Runtime exception I am assuming?
class Product{
#Transactional
addDetails(){
try{
}
catch (Exception e) {
throw new Exception("Details dont match") //Line 4
}
productDAO.save(productDetails)
addAdditionalDetails(productDetails)
}
}
class ProductDAO {
#Transactional
public void save(Product productDetails){
entitiyManager.merge(productDetails)
}
}
I am also trying to understand if the exception thrown at line #4 is a
checked or unchecked exception?
Answer: java.lang.Exception is a checked exception.
If I am throwing "throw new Exception("Details don't match")" it is a
Runtime exception I am assuming?
Answer: No, it is not a RuntimeException. RuntimeException is those which extends java.lang.RuntimeException or its subclass.
In spring by Transaction is Rollback when a Runtime exception occurs. That means any exception thrown in a transaction which extends RuntimeException or its subclass will rollback it. But in your case, you are throwing Exception which is not a type of RuntimeException.
Solution:
I will suggest creating a Custom exception which extends RuntimeExction and throws it.
class UnmatchedDetailException extends RuntimeException{
UnmatchedDetailException(String msg){
super(msg);
}
}
And then throw the UnmatchedDetailException
throw new UnmatchedDetailException("Deatils not matched");
With default spring configurations, only un-checked runtime exceptions are rolled back. In order to customize this configuration, rollbackFor is used as a property in the #Transactional annotation.
For ex,
#Transactional(rollbackFor = { MyInvalidUserException.class,
MyApplicationException.class }) public void method() throws
MyInvalidUserException, MyApplicationException {
...
... }
Related
I have this code:
#SneakyThrows
public void startDatabase() throws NotBoundException, RemoteException {
entityRepository = new EntityRepositoryImpl(DatabaseManagerImpl.getInstance());
registrar = new RegistrarImpl(entityRepository);
String process = ManagementFactory.getRuntimeMXBean().getName();
registrar.register();
LOG.debug("Started database with process id: " + process);
}
In which it throws an exception NotBoundException, RemoteException adding the #SneakyThrows annotation makes the IDE report that both these two exceptions are not thrown by the method (anymore).
Does Lombok SneakyThrows actually stop an exception from propagating?
No, it does not prevent the exception from propagating.
#SneakyThrows can be used to sneakily throw checked exceptions without actually declaring this in your method's throws clause.
Reference: https://projectlombok.org/features/SneakyThrows
I'm using #Transactional in my code and I'm created a custom exception to show error messages in specific format in UI.
public class MyCustomException extends RuntimeException
When this exception is encountered I still want to rollback my transactions, same as in case when any other exception occurs.
So to make it work, I writing below code:
// service method called from rest controller
public List<String> getMyData() {
List<String> errors = new ArrayList();
try {
businessMethod();
} catch (MyCustomException e) {
log.error(e.getMessage);
errors.add(e.getMessage)
}
return errors.
}
#Transactional(rollbackFor = {MyCustomException.class, RuntimeException.class, Exception.class})
public String businessMethod() {
// Business logic to get data that can throw MyCustomException
}
My questions are:
If I'm mentioning MyCustomException.class in rollbackFor, do I need to also mention RuntimeException.class, Exception.class. Or whatever is mentioned in rollbackFor gets appended along with default exceptions for which transaction is rolled-back.
Although I'm escaping the MyCustomException from businessMethod(), but I'm catching it on its calling method getMyData(). I'm assuming that the transaction will be rolled-back in case of exception, correct?
The transaction will be rolled back on any RuntimeException, so it is not necessary to declare your own MyException.class in rollbackFor section, since your MyException extends RuntimeException. If you declare Exception.class the rollback will be performed on any Exception. But in your case you do not need rollbackFor at all.
Yes, it is correct. Your transcation starts and ends in businessMethod().
I've created my own exception class:
public class ValidationException extends RuntimeException { ... }
I've declared it in EJB interface method:
public interface MyApi {
void save(MyDTO dto) throws ValidationException;
}
Now I've used it in the implementation:
#Stateless
#Local(MyApi.class)
public class MyService implements MyApi {
public void save(MyDTO dto) throws ValidationException {
...
throw ValidationException(errorMessages);
}
}
However, when I call that method:
#Path("/my")
#Stateless
public class MyChannel {
#Inject private MyApi myApi;
public void save(MyDTO dto) {
try{
myApi.save(dto);
} catch (ValidationException ex) {
// do sth with the exception
}
}
}
Instead of expected ValidationException, the EJBException is thrown with the following message:
0000167f BusinessExcep E CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "save" on bean
It surprised me, because the exception is declared in the interface and in the implementation. How else can I declare the exception, in order to be able to use it to communicate errors to the caller?
The whole mayhem happens on the WebSphere 8.5. I'm using EJB 3.0 and WebSphere libraries. The channel is JSON REST channel in the WAR module, which is wrapped in EAR module.
I believe the root of your problem lies in choosing to have your custom ValidationException extend RuntimeException. Within Java, RuntimeException or any subclass of RuntimeException does not have to be declared using a throws clause on a method signature. The intent of RuntimeException is that it is generally used in unrecoverable bug scenarios that are the result of something done incorrectly by the method caller, such as attempting to traverse beyond the end of an array (ArrayIndexOutOfBoundsException) or passing an invalid parameter (IllegalArgumentException).
Given that you would like to make your ValidationException part of the method signature and thereby require the calling client to handle the exception, I suggest the following change:
//Modify your exception so that it
//subclasses Exception (not RuntimeException):
public class ValidationException extends Exception { ... }
You will not have to modify the MyService interface, because the save method already declares that it throws the exception. But this small change will shift the way Java handles ValidationException so that when the exception is thrown, it will behave in the way you expect (and without the extraneous noise about an "undeclared" exception).
Use the #ApplicationException annotation. For example
#ApplicationException
public class ValidationException extends RuntimeException {
private static final long serialVersionUID = 7797343376699439504L;
}
You can use it with RuntimeException so you don't have to use throws declarations.
I am implementing an JEE7 web application. During my work i have found a problem with handling my custom exceptions.
I edited my account's property to have a non-unique login field. Then i invoked the AccountEditBean#editAccount() to run the editing process. When the process comes to AccountFacade#edit() i can see (in debug) that PersistenceException is caught and my custom NonUniqueException is thrown. The problem is, the exception is not propagated out of the facade class and it is not handled in AccountEditBean. Instead of that TransactionalException occurs right after throw:
WARNING: EJB5184:A system exception occurred during an invocation on
EJB ADMEndpoint, method: public void
pl.rozart.greatidea.adm.endpoints.ADMEndpoint.editAccount(pl.rozart.greatidea.entities.Account)
throws pl.rozart.greatidea.exceptions.BaseApplicationException
WARNING: javax.transaction.TransactionalException: Managed bean with
Transactional annotation and TxType of REQUIRES_NEW encountered
exception during commit javax.transaction.RollbackException:
Transaction marked for rollback.
Additional information:
NonUniqueException extends BaseApplicationException , which is marked as #ApplicationException(rollback=true).
Here's the code for the edit process:
AccountEditBean:
#Named(value = "accountEditBean")
#ViewScoped
public class AccountEditBean extends UtilityBean implements Serializable {
#Inject
ADMEndpointLocal admEndpoint;
private Account account;
public void editAccount() {
try {
admEndpoint.editAccount(this.account);
Messages.addInfo(ACCOUNT_DETAILS_FORM, KEY_CHANGES_SUCCESS);
} catch (NonUniqueException e) {
Messages.addError(ACCOUNT_DETAILS_FORM, e.getMessage());
} catch (BaseApplicationException e) {
Messages.addFatal(ACCOUNT_DETAILS_FORM, e.getMessage());
}
}
}
ADMEndpoint:
#Stateful
#Transactional(Transactional.TxType.REQUIRES_NEW)
#TransactionTracker
public class ADMEndpoint extends LoggingStateBean implements ADMEndpointLocal, SessionSynchronization {
#EJB(name = "ADMAccountFacade")
private AccountFacadeLocal accountFacade;
private Account account;
#Override
public void editAccount(Account account) throws BaseApplicationException {
this.account.setLogin(account.getLogin());
this.account.setEmail(account.getEmail());
accountFacade.edit(this.account);
}
}
ADMAccountFacade:
#Stateless(name = "ADMAccountFacade")
#Transactional(Transactional.TxType.MANDATORY)
#TransactionTracker
public class AccountFacade extends AbstractFacade<Account> implements AccountFacadeLocal {
#PersistenceContext(unitName = "myPU")
private EntityManager em;
#Override
public void edit(Account account) throws BaseApplicationException {
try {
em.merge(account);
em.flush();
} catch (PersistenceException e){
if(e.getMessage().contains(Account.CONSTRAINT_ACCOUNT_LOGIN_UNIQUE)){
throw new NonUniqueException(NonUniqueException.MSG_NON_UNIQUE_ACCOUNT_LOGIN, e);
}else{
throw new BaseDatabaseException(BaseDatabaseException.MSG_GENERAL_DATABASE_ERROR, e);
}
}
}
}
Do you know what could be the cause of the problem? It occurs in every of my facades, with all the custom exceptions.
I think you should change #Transactional to #TransactionAttribute because EJBs annotated with that. #Transactional is put on managedbean in java 7 not in EJBs...
I copied my comment here because i do not have enough points to squander :)
You are throwing an exception from a method whose invocation will be intercepted at runtime and additional logic wrapped around it:
transaction management;
exception handling.
Your exception cannot transparently jump over that logic, and the specification (probably) says a TransactionalException will be thrown, wrapping your original exception (again, probably---I am not that intimate with the details).
I have an EJB Web Service. I have created custom fault classes that are thrown by web service methods and this works great. My client catches those custom exceptions and handles them fine. The issue I've run into is that if an exception happens in the constructor of the bean and I throw my custom exception the client doesn't receive my custom exception it receives the following:
javax.xml.ws.soap.SOAPFaultException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
at $Proxy34.getLots(Unknown Source)
My question is: can custom exceptions be thrown in the constructor of an EJB and be received from the client? If so what am I doing wrong.
My code:
EJB Constructor
public LotManagement() throws LotManagementException
{
try {
pm = new PromisManager();
} catch (UnknownHostException ex) {
java.util.logging.Logger.getLogger(LotManagement.class.getName()).log(Level.SEVERE, null, ex);
} catch (IOException ex) {
FaultBean LotManagementFaultBean = new FaultBean();
throw new LotManagementException(ex.getMessage() + "\n\n" + propMan.getProperty("ContactMessage"), LotManagementFaultBean, ex.getCause());
}
}
Fault Bean
package com.onsemi.cim.exception;
import javax.xml.ws.WebFault;
#WebFault(name="LotManagementException")
public class LotManagementException extends Exception {
private static final long serialVersionUID = 1L;
private FaultBean faultBean;
public LotManagementException() {
super();
}
public LotManagementException(String message, FaultBean faultBean,
Throwable cause) {
super(message, cause);
this.faultBean = faultBean;
}
public LotManagementException(String message, FaultBean faultBean) {
super(message);
this.faultBean = faultBean;
}
public FaultBean getFaultInfo() {
return faultBean;
}
}
Possible solution can be that you try to catch the exception inside your constructor and handle all exceptions there. Come on an agreement with your client that you will either throw an exception or will send some custom error message like status 0/1 etc and based upon the response code they can decide to work accordingly.
Also I will encourage you not to throw even custom exception and try sending error messages because in future if for some reason you need to replace your custom error mechanism then you need to ask you client to do some changes accordingly.
Actually it is not a good idea to throw exceptions from constructors because different APIs (Like Spring) treat them differently. You are getting that error because when you get an exception from EJB constructor it throws CreateException.
So my opinion will be to check and possible remove the exception from constructor.