DuplicateKeyException thrown when an attempt to insert or update data results in violation of a primary key or unique constraint.
DataIntegrityViolationException thrown when an attempt to insert or update data results in violation of an integrity constraint.
There are many scenarios where data constraint exceptions will occur, such as: the field is not empty
* <p>Serves as a superclass for more specific exceptions, e.g.
* {@link DuplicateKeyException}. However, it is generally
* recommended to handle {@code DataIntegrityViolationException}
* itself instead of relying on specific exception subclasses.
@YunWZ I see the DataIntegrityViolationException and DuplicateKeyException commend, Spring recommend to handle DataIntegrityViolationException but not DuplicateKeyException , should we revert to handle DataIntegrityViolationException?
commend in DuplicateKeyException
* ....
* <p>Consider handling the general {@link DataIntegrityViolationException}
* instead, semantically including a wider range of constraint violations.
* @author Thomas Risberg
and commend in DataIntegrityViolationException
* <p>Serves as a superclass for more specific exceptions, e.g.
* {@link DuplicateKeyException}. However, it is generally
* recommended to handle {@code DataIntegrityViolationException}
* itself instead of relying on specific exception subclasses.
Well, that's a good suggestion, we should handle all exception cases instead of just `DuplicateKeyException.
Of course, in this case we should to do two things:
When catching DuplicateKeyException, we need to update record;
Otherwise, tell the method's caller some information (for example, throw an exception).Because users may customize their owner database plugin.
What do you think?
