Spring @Repository Exception Translation
Fast recall
Quick revision
Core answer
Understanding of a concrete technical benefit @Repository provides beyond just bean registration
Not knowing this feature exists or thinking @Repository is purely a naming convention
Explain the PersistenceExceptionTranslationPostProcessor bean that performs this translation and why vendor independence matters in production systems
Interview-ready guide
Interview answer
Persistence providers expose different exception types. Spring can translate recognized exceptions from an advised @Repository bean into its unchecked DataAccessException hierarchy, allowing service code to handle categories such as integrity violations without importing one vendor's exception class. This relies on exception-translation infrastructure and a suitable persistence exception translator; @Repository is the marker. Spring Boot commonly configures this infrastructure with its data-access support. Translation makes categories portable, but it does not turn database messages into user-safe API errors or guarantee identical detail across vendors.
Spring @Repository Exception Translation
Direct Answer
@Repository marks a persistence component as eligible for Spring's exception translation. When a PersistenceExceptionTranslationPostProcessor is configured—as Spring Boot persistence setups commonly do—exceptions from supported persistence technologies can be translated into Spring's DataAccessException hierarchy. The annotation by itself does not rewrite every exception, and errors such as constraint violations still need application-level interpretation.
Code Example
@Repository
public class UserRepository {
private final JdbcTemplate jdbcTemplate;
public UserRepository(JdbcTemplate jdbcTemplate) {
this.jdbcTemplate = jdbcTemplate;
}
public void save(User user) {
// If email already exists, throws SQLException with code 23505 (unique violation)
jdbcTemplate.update(
"INSERT INTO users (email, name) VALUES (?, ?)",
user.email(), user.name()
);
}
}
@Service
public class UserService {
private final UserRepository repository;
@Transactional
public void registerUser(User user) {
try {
repository.save(user); // Repository throws vendor-specific exception
} catch (DuplicateKeyException e) { // Service catches Spring's common exception
throw new BusinessException("Email already registered");
}
}
}
Common Mistakes & Pitfalls
- Not using @Repository at all: Freshers sometimes use @Component for data access classes, losing exception translation entirely. When SQLException leaks into the service layer, they're forced to add persistence dependencies.
- Catching generic Exception: Writing catch (Exception e) in the service defeats the purpose because you can't distinguish a duplicate key error from a connection timeout. Use Spring's specific subclasses like DataIntegrityViolationException or OptimisticLockingFailureException.
- Assuming all exceptions are translated: Only exceptions thrown from @Repository beans get translated. If you manually create a DataSource connection outside Spring's management, translation won't happen.
Check your understanding
Answer these without looking back at the article.
- What is DataAccessException in Spring?
- Do Spring Data JPA repositories need @Repository?
- What is PersistenceExceptionTranslationPostProcessor?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.