In an earlier section, we discussed handling of exceptions in short. Let's find out about it in more detail. The JDBC code forces handling of exceptions through checked exceptions. However, they are generalized, and handled only through DataTrucationException, SQLException, BatchUpdateException, and SQLWarning. As opposed to JDBC, Spring supports various unchecked exceptions for different scenarios, providing specialized information. The following table shows a few of which we may need frequently:
|
Spring Exceptions |
When are they thrown? |
|
DataAccessException |
This is the root of the Spring Exception hierarchy; we can use it for all situations |
|
PermissionDeniedDataAccessEception |
This is used when you try to access data without the correct authorization to access it |
|
EmptyResultDataAccessException |
This is on no row returned from the database but, at least, one is expected |
|
IncorrectResultSizeDataAccessException |
This is when the result size does not match with the expected result size |
|
TypeMismatchDataAccessException |
This is on mismatch of the data type between Java and the database |
|
CannotAccqireLockException |
This is raised on failure to acquire the lock while trying to update the data |
|
DataRetrivalFailureException |
This is when you search and retrieve the data using ID using the ORM tool |
While handling the database operations using Spring DataSource, Template classes, and DAOSupport classes, we are still involved in JDBC operations using SQL queries without object-centric operations. The easy way to handle database operations is by keeping the object at the center using object relational mapping (ORM).