-
1. Re: Unable to catch RuntimeException in client EJB
take-4c-ktym Sep 27, 2012 6:03 AM (in response to bibhu)Hi,
Had you already solved this problem ?
I have a question.
Though SecurityBreakException extends RuntimeException,
the design is proper ?I think that RuntimeException is categorized in system exception
and it is generally in the case that there is no proper implementation even if catching it.
Ex) NullPointerException, ArrayOutOfBoundsException, etcSo, how about stopping the way that SecurityBreakException extends RuntimeException ?
-
2. Re: Unable to catch RuntimeException in client EJB
bibhu Dec 12, 2012 9:17 PM (in response to take-4c-ktym)Hi Katayama,
sorry for my late reply.
No, the problem is not solved yet.
I think the design is correct.We can't throw a checked exception from the method public void onPostInsert(final PostInsertEvent event) ..So, I am bound to make SecurityBreakException extend RuntimeException.
-
3. Re: Unable to catch RuntimeException in client EJB
jmartisk Dec 13, 2012 7:32 AM (in response to bibhu)I guess you cannot work around the fact that the exception will be wrapped. But you still can try to catch the wrapper exception and inspect it to see if the exception inside is your SecurityBreakException, can't you?
catch (EJBTransactionRolledbackException e) { if(e.getCause() instanceof SecurityBreakException) { SecurityBreakException ex = (SecurityBreakException)e.getCause(); // parse the exception and show a meaningful message to user } }
-
4. Re: Unable to catch RuntimeException in client EJB
bibhu Dec 13, 2012 9:03 AM (in response to jmartisk)Hi Jan,
First of all thanks for your answer.
Catching the EJBTransactionRolledbackException will help to show a meaningful message to user.
But handling a generice exception like EJBTransactionRolledbackException might not be a good idea. It may eat the exceptions where I dont want this scenario and distrurb everything. -
5. Re: Unable to catch RuntimeException in client EJB
jmartisk Dec 13, 2012 9:09 AM (in response to bibhu)In that case you can just rethrow the
EJBTransactionRolledbackException so you don't lose it..
catch (EJBTransactionRolledbackException e) { if(e.getCause() instanceof SecurityBreakException) { SecurityBreakException ex = (SecurityBreakException)e.getCause(); // parse the exception and show a meaningful message to user } else throw e; }
-
6. Re: Unable to catch RuntimeException in client EJB
bibhu Dec 15, 2012 8:32 AM (in response to jmartisk)As per your suggestion,I tried catching the
EJBTransactionRolledbackException,but no luck.
The exception is thrown out side of the try() block i.e.exception is thrown after the execution of this method.Below is my understanding on why it is not able to catch .let me know if doesn't make any sense.
I am using EJB with Seam on server side and GWT (dont bother ;just a GUI tehnology like JSF)on client side.
@Local public interface SaveUserDataService{
public void save(Person person);
}
//client EJB which expects a SecurityBreakException
@Stateful SaveUserDataServiceBean implements SaveUserDataService{
public void save(Person person){
try{ //code to call dao layer to save a person
} catch (SecurityBreakException e) {
// parse the exception and show a meaningful message to user
}
}
}
When user clicks on save button , the request comes to save() method of SaveUserDataServiceBean which is the boundary ejb .
Transaction begins when the call stack starts and commits when the call stack ends.Call stack is basically the stack of methods consists of all the methods starting from the boundary method (root of the stack ie "save(Person person) ") till the last call to DAO ;basically all nested method calls.
So, container commits/rolls back the transaction when the stack ends i.e. the boundary method completes execution, and DataChangeListener is triggered just before the commit.
Thanks
Bibhu
-
7. Re: Unable to catch RuntimeException in client EJB
jmartisk Dec 18, 2012 4:35 AM (in response to bibhu)Oh yeah, I kind of thought so.. I guess you can't catch the exception if it goes from the onPostInsert callback, because that metod is called asynchronously to any of your other invocations - after you finish your EJB call.
I guess you can either
- try to throw the exception earlier than during commit, for example right from the "save" method?
- use bean-managed transactions and try to do the commit yourself in the end of the "save" method - and if the commit fails, you can parse the exception from it.