I'm middle of a middle-sized software development project with Spring Boot 5 console application with Spring Data Jpa. (not a Web Project)
I'm using entity->service->repository structure in order to persist records.
In order to handle exceptions; I've been using MyExceptionHandler (which is extended to java.lang.Exception and created by me) that help me to format stack-trace into console. Additionally; I'm saving it into a file (exceptions.log)
I'm using MyExceptionHandler in all my infinite count #Service classes, and XxxUtil.java (DateUtil, EncryptionUtil etc.)
I need to save Exception content into a database table. (Message and Formatted Detail is enough for now - I've extracted formatted detail string with root cause)
Autowiring a service or a repository in MyExceptionHandler class produces NullPointerException which is expected. I need your help to bypass this step.
I'm open to your alternative solutions like "Why don't you use SL4J DBAppender" etc.
try {
//some actions
} catch (Exception e) {
saveExceptionToDatabase(e);
new MyExceptionHandler("MyClass.myMethod()", e);
}
Thanks for your guidance
Related
I have a SpingBoot project that uses Spring Data Jpa as its repository level abstraction. I have a repository that extends JpaRepository interface. I call the save() method from within my Service layer as follows :
myCustomeRepository.save(new ObjectXYZ(abc,xyz));
I also observed that the save() method inherited from the CrudRepository throws IllegalArgumentException when receiving null entities.
Should I go ahead and try to catch the IllegalArgumentException in my Service layer ?i.e.
try{
myCustomeRepository.save(new ObjectXYZ(abc,xyz));
}catch (IllegalArgumentException iae){
}
NOTE: I have already implemented validation(#NotEmpty) at the DTO level using Hibernate Validator.
IllegalArgumentException extends RuntimeException, so the compiler will not force you to catch it.
Whether you catch it or not depends on what you want to do if it occurs:
If you expect it to never happen, because of the validation you have in place, then don't catch it. If it does happen (e.g. there's a problem with your validation) then your application will fail and you will find out that there's a problem.
If it indicates that the client has passed bad data to your service layer, you could catch it and do whatever your service layer does to report invalid data to its clients, or you could just not catch it, and (assuming you are writing a web application) have a global mapping of the exception to a 400 bad request status.
What you should not do is catch it and ignore it, because then you will have difficulty figuring out what is wrong with your system if it is ever thrown.
I've a MQ Spring Boot PaaS application where I need to implement exception handling via a common exception handler class (GlobalExceptionHandler). My PaaS application receives message from a source queue, perform some database operations via spring jpa and write the response back to a destination queue.
I need to handle all the database RuntimeException, custom business exceptions and other checked exceptions via GlobalExceptionHandler class.
My GlobalExceptionHandler will have handlers (method) defined for every exception. In my handler, I will be logging the exception first and then I will be creating a [error code, desc] and then I need to return it back to main flow.
I do not have any controller in my application. So I think, I can't use #ControllerAdvice. Currently I'm using spring AOP #AfterThrowing as below but I'm not able to return the [code, desc] from handlers.
#AfterThrowing(pointcut = "execution(* com.abc.xyz.service..*(..)) ",
throwing = "dataNotFoundException")
public void handleDataNotFoundException(DataNotFoundException dataNotFoundException) {
LOGGER.info("Info : " + dataNotFoundException.getMessage());
// code, desc need to create here and send it back to calling place.
// I need to change the return type here from void.
}
Can anyone please guide me in implementing exception handling here.
As I explained here, #AfterThrowing cannot modify return values or otherwise change the execution flow of your epplication. You cannot even catch the exception there. You need to use an #Around advice instead.
I suggest you read some documentation first and then ask more follow-up questions.
We have an app that is using hibernate, spring, and DB2 in websphere 7. We have audit triggers and we need to set so the triggers can know the logged in user (we use generic logon to the database). We came up with a new scheme for setting this in a new app so that it can automatically join in new transactions. We overrode the transaction manager and did the work in the doBegin.
These scheme worked great in one app, and seemed to work great in a second app, but now, weeks later, and not consistently (behavior is intermittent and does not happen in local development), we are getting this Pre-bound JDBC Connection found error. Looking online most posts say this is when you use two transaction managers against one data source. That is now what we are doing.
I also read one post wondering if it was because he mixed annotation and AOP based transactions. This app does some of that. I don't really buy that theory, but thought I'd mention it.
Exception:
Caused by:
org.springframework.transaction.IllegalTransactionStateException: Pre-bound JDBC Connection found! HibernateTransactionManager does not support running within DataSourceTransactionManager if told to manage the DataSource itself. It is recommended to use a single HibernateTransactionManager for all transactions on a single DataSource, no matter whether Hibernate or JDBC access.
at java.lang.Throwable.<init>(Throwable.java:67)
at org.springframework.core.NestedRuntimeException.<init>(NestedRuntimeException.java:54)
at org.springframework.transaction.TransactionException.<init>(TransactionException.java:34)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:475)
at gov.usdoj.afms.umc.utils.hibernate.AfmsHibernateTransactionManager.doBegin(AfmsHibernateTransactionManager.java:28)
Code (note that the exception comes from the super.doBegin()):
protected void doBegin(Object arg0, TransactionDefinition arg1) {
super.doBegin(arg0, arg1);
if (!Db2ClientInfo.exists()) {
clearDBProperty();
} else {
setDBProperty(Db2ClientInfo.getClientUserId(), Db2ClientInfo.getClientApplicationId());
}
}
private void setDBProperty(String uId, String appName) {
Session session = getSessionFactory().getCurrentSession();
Properties props = new Properties();
props.setProperty(WSConnection.CLIENT_ID, uId);
props.setProperty(WSConnection.CLIENT_APPLICATION_NAME, appName);
try {
Connection nativeConn = new SimpleNativeJdbcExtractor().getNativeConnection(session.connection());
if (nativeConn instanceof WSConnection) {
WSConnection wconn = (WSConnection) nativeConn;
wconn.setClientInformation(props);
} else {
logger.error("Connection was NOT an instance of WSConnection so client ID and app could not be set");
}
} catch (Exception e) {
throw new RuntimeException("Cannot set DB parameters!", e);
}
}
I just realized I never answered this. It turns out that the exception had nothing whatever to do with our Tx manager. It was the fact that this particular EAR has two apps in it, each pointing to the same data source. Evidently this confuses hibernate. We've plans to separate the apps some day, but creating an identical (except in name) data source and pointing the apps at them separately fixes the issue for now.
Instead of modifying the transaction manager it might be easier (better?) to create a wrapper around your datasource (extending DelegatingDataSource from spring) and override the 2 getConnection methods. For the cleanup you could wrap the connection in a proxy and intercept the close method.
That should be a safer (and easier I guess) way then trying to fiddle with the transaction manager and it works for every technology (JDBC, Hibernate, JPA etc.) as long as you use the wrapped datasource. (The registration could be done with a BeanPostProcessor which detects DataSource instances and simply wraps them in the delegate).
If that is to radical (as it means changing your current applications instead of updating a library). It could be a configuration problem, make sure that you are only loading your configuration (and thus DataSource and TransactionManager) only once, duplicating bean instances might lead to a similair behavior.
For posterity, I just got this problem and the answers here weren't very helpful. We resolved the problem by removing a double import of a core XML file which had the AOP transaction manager definition in it:
<tx:annotation-driven transaction-manager="..."
proxy-target-class="true" />
I'm thinking that it causes there to be 2 transaction managers overlapping the same namespace. To fix it, we moved the imports around so they were being done once.
Hope this helps someone else.
I am using Spring Hibernate integration in my application and DAO classes are extending HibernateDaoSupport.
Suppose I save some object using the code
getHibernateTemplate().save(object);
As Spring Hibernate integration doesn't mandate to write try-catch block, but suppose if any exception is thwron while saving that object.
Then what is the best way to handle it? I means should I catch it in the service layer and wrap it in some user defined excpetions.
Do I need to write try-catch in DAO layer method itself in case I want to log which method in DAO throws exception?
I have never used HibernateDaoSupport or Hibernate Template before so ignorant about exception handling. Please provide me your valuable inputs
The idea behind Spring using RuntimeException is that generally there are different types of exception:
Exceptions that you want to recover from (such as a DuplicateKeyException if a record that you're trying to insert already exists or the more general DataIntegrityViolationException if there was a DB constraint that was violated as a result of user input)
Exceptions that you can't recover from (the database is down)
For the first case, you may well handle the exception (either through a custom business exception, so that the view layer can redirect to the input page and provide a meaningful message)
For the second case, it would be easier to let the exception bubble up and have it handled by a generic exception handler that then displays a generic error page to the user. For this scenario it doesn't make sense to wrap the exception in a custom exception as you won't be able to recover. A blown up DB tends to be fatal.
So what I would do:
try {
getHibernateTemplate().save(object);
} catch (DataIntegrityViolationException dive) {
throw new BusinessValidationException(dive, "You've got the data wrong");
}
Spring exception hierarchy is well documented.
Usually you can't do much if you have a data access exception, because in the working system this may be caused by the shortage of diskspace on the DB server, or network connection problems etc.
Such exceptions are usually need to be logged and investigated as soon as possible.
There some recoverable errors, they can be handled with spring exception hierarchy, but imho most of them should be avoided during the developing phase, so your web server should validate as many things as possible, before it goes to the db.
If you want to set the exception logging see the similar questions:
Exception handler in Spring MVC
Spring MVC Best Practice Handling Unrecoverable Exceptions In Controller
I am writing a service layer which uses Entity framework to get/set data from the database, and then pass it to an MVC web application. I am not able to decide what is the bext way to return database errors to the web application.
Should I throw an exception and the web application can handle it accordingly, or should I return a string/bool to convey that the database action has worked or not?
Any suggestion on what is the best practice?
Thanks
You can either not handle them in your service layer, or you can normalize them using an exception class that you will create. For example:
public class DatabaseException: Exception
{
public string TableName { get; private set; }
public DatabaseException(string tableName, Exception innerException)
:base("There a database error occured.", innerException)
{
TableName = tableName;
}
}
Simply add whatever information you require to the exception class as properties and initialize them in the constructor.
It's really not the best practice to inform the higher levels about exceptions with return values, since most of the methods are already returning some data.
You should not handle exception thrown out from web application, let exception thrown naturally, even from data access layer. With this way, it is easy for you for troubleshooting, esp in production stage. So, how to handle:
Use custom error page for exceptions thrown out.
Use HttpModule to log exception for troubleshooting. ELMAH, loggin module, works perfectly with ASP.NET MVC and alows you to view logs on web.