Best practice propagating Unique Violation Exceptions to UI

Question

We are working on Java web project based on JPA 2, Hibernate, Spring 3 and JSF 2 running in Tomcat 7. We are using Oracle 11g as database.

We are currently holding a debate on approaches to populate database constraint violations as user-friendly messages to the UI. More or less we see two ways, both are not really satisfying. Could somebody give some advise?

Approach 1 - Validate programmatically and throw specific exception

In CountryService.java each Unique constraint will be validated and a corresponding exception is thrown. The exceptions are handled individually in a backing bean.

Advantage: Easy to understand and maintain. Specific User messages possible.

Disadvantage: A lot of code just for having nice messages. Basically all DB Constraints are written again in the application. A lot of queries - unnecessary db load.

@Service("countryService") public class CountryServiceImpl implements CountryService {      @Inject     private CountryRepository countryRepository;      @Override     public Country saveCountry(Country country) throws NameUniqueViolationException,  IsoCodeUniqueViolationException, UrlUniqueViolationException {         if (!isUniqueNameInDatabase(country)) {             throw new NameUniqueViolationException();         }         if (!isUniqueUrl(country)) {             throw new UrlUniqueViolationException();         }         if (!isUniqueIsoCodeInDatabase(country)) {             throw new IsoCodeUniqueViolationException();         }         return countryRepository.save(country);     } } 

In the View's Backing Bean you handle the exceptions:

@Component @Scope(value = "view") public class CountryBean {      private Country country;      @Inject     private CountryService countryService;      public void saveCountryAction() {         try {             countryService.saveCountry(country);         } catch (NameUniqueViolationException e) {             FacesContext.getCurrentInstance().addMessage("name", new FacesMessage("A country with the same name already exists."));         } catch (IsoCodeUniqueViolationException e) {             FacesContext.getCurrentInstance().addMessage("isocode", new FacesMessage("A country with the same isocode already exists."));         } catch (UrlUniqueViolationException e) {             FacesContext.getCurrentInstance().addMessage("url", new FacesMessage("A country with the same url already exists."));         } catch (DataIntegrityViolationException e) {              // update: in case of concurrent modfications. should not happen often              FacesContext.getCurrentInstance().addMessage(null, new FacesMessage("The country could not be saved."));         }     } } 

Approach 2 - Let the database detect constraint violations

Advantage: No boiler plate code. No unnecessary queries to db. No duplication of data constraint logic.

Disadvantage: Dependencies to constraint names in DB, so generation of Schema through hibernate not possible. Mechanism needed to bind messages to input components (e.g. for highlighting).

public class DataIntegrityViolationExceptionsAdvice {     public void afterThrowing(DataIntegrityViolationException ex) throws DataIntegrityViolationException {          // extract the affected database constraint name:         String constraintName = null;         if ((ex.getCause() != null) && (ex.getCause() instanceof ConstraintViolationException)) {             constraintName = ((ConstraintViolationException) ex.getCause()).getConstraintName();         }          // create a detailed message from the constraint name if possible         String message = ConstraintMsgKeyMappingResolver.map(constraintName);         if (message != null) {             throw new DetailedConstraintViolationException(message, ex);         }         throw ex;     } } 

Answer 1

Approach 1 will not work in a concurrent scenario! -- There is always a change that somebody else insert a new database record after you checked but before you added your database record. (except you use isolation level serializable, but this is highly unlikely)

So you have to handle the DB constraint violation exceptions. But I recommend to catch the database exception that indicates the unique violation and throw a more meaning full like you suggested in Approach 1.