Spring provides a set of implementation technology independent, DAO layer semantic level exception system, through internal converters to different persistence technology exceptions into Spring exceptions for unified management.
1 Abnormal system
Many orthodox aps use so many checking exceptions that when using the API, the code is filled with try/catch boilerplate code. For the most part, these catch pieces don’t do much useful work beyond logging.
The JDBC API in the JDK, for example, is poorly used because checking exceptions are rampant and a lot of exception-handling code intrudes into the business code, ruining the cleanliness and elegance of the code as a whole.
Spring provides an elegant system of dao exceptions in org.springframework.dao, which inherit from DataAccessException, DataAccessException inherits from NestedRuntimeException, which encapsulates the source exception in a nested manner. Thus, although specific exceptions from different persistence techniques are translated into Spring’s DAO exception architecture, we can obtain raw exception information through the getCause() method.
This exception architecture defines an exception directory tree from the DAO’s level of abstraction, which makes it easy for developers to focus on a particular semantic exception. JDBC’s SQLException is low-level and database-specific (such as getErrorCode()), which is not only hard to code but also hard to transplant.
Spring establishes an exception classification directory that classifies the exception types with appropriate granularity. The benefits of this are:
- Developers can be freed from the tedious technical details at the bottom.
- Developers can choose which exceptions they are interested in handling.
DataAccessException has these exception subclasses:
Exception subclasses | instructions |
---|---|
CleanupFailureDataAccessException | The DAO operation succeeds, but an exception occurs when data resources are released, for example, an exception occurs when Connection is closed. |
ConcurrencyFailureException | Exceptions occur when data is concurrently manipulated, such as failure to obtain optimistic or pessimistic locks, deadlock failures, etc. |
DataAccessResourceFailureException | Failure to access data resources, such as failure to obtain data connections, failure to obtain Hibernate sessions and other scenarios. |
DataRetrievalFailureException | Failure to obtain data, such as a scenario where the data corresponding to the primary key cannot be found or the wrong column index is used. |
DataSourceLookupFailureException | The data source could not be looked up from JNDI. |
DataIntegrityViolationException | Thrown when data operations violate data consistency limits, such as inserting duplicate primary keys or referencing non-existent foreign key scenarios. |
InvalidDataAccessApiUsageException | Thrown when one of the persistence techniques is incorrectly called, such as when a query object in Spring JDBC is not compiled before being called. This exception is mainly due to incorrect use of persistence techniques. |
InvalidDataAccessResourceUsageException | Thrown when an incorrect method was used to access a data source, such as a miswritten SQL statement. |
PermissionDeniedDataAccessException | Thrown when the data access permission is insufficient. Try to change data when you only have read-only permission. |
UncategorizedDataAccessException | Other exceptions that are not classified. |
To further refine the error problem domain, Spring subdivides these first-level exception classes.
The exception architecture is highly extensible, and when Spring needs to support a new persistence technology, it simply defines a child exception for it, which implements the “open close principle” of the design pattern.
Open-closed principle (OCP) is the cornerstone of reusable design in object-oriented design. It is one of the most important principles in object-oriented design. Many other design principles are a means to implement open-closed principle. Being open for extension and closed for modification means that the behavior of a module can be extended. As the requirements of the application change, we can extend the module to have new behaviors to meet those changes.
2 Abnormal Converter
2.1 the JDBC
Typically, the JDBC API throws a SQLException when an exception occurs during a data operation. SQLException encapsulates the details of the exception in an exception attribute, so if you want to understand the specific cause of the exception, you must analyze the exception attribute.
SQLException has two attributes that represent the specific cause of the exception:
attribute | type | instructions |
---|---|---|
Error code | int | Call specific to a specific databasegetErrorCode() To return. |
SQL status code | String | Standard error code, consisting of 5 characters, calledgetSQLState() To return. |
Spring converts the SQLExeption into the corresponding Spring DAO exception based on the error code and SQL status code. In the org. Springframework. JDBC. Support SQLExceptionTranslator interface is defined in the package, Two of the interface implementation class SQLErrorCodeSQLExceptionTranslator and ` SQLStateSQLExceptionTranslator respectively responsible for handling the SQLException error code and the SQL status code conversion work.
2.2 Other ORM persistence techniques
Other ORM persistence technologies have a semantically explicit exception system, so the transformation is relatively simple.
** Note: **Spring4 only supports Hibernate3.6+.
Spring defines subpackages for supported ORM technologies in org.springframe.orm. The corresponding exception converters are also defined in these subpackages:
ORM persistence technology | Abnormal converter |
---|---|
HibernateX can be 3, 4, or 5 | org.springframework.orm.hibernateX.SessionFactoryUtils |
JPA | org.springframework.orm.jpa.EntityManagerFactoryUtils |
JDO | org.springframework.orm.jdo.PersistenceManagerFactoryUtils |
These utility classes provide the ability to return the same session from the transaction context, in addition to the exception conversion capability, during transaction management.
Spring also supports myBatis persistence technology, because myBatis throws the same exceptions as JDBC, which are SQLException exceptions, so it uses the same exception converter as JDBC.