Map weird Hibernate exceptions to nice MIsk exceptions

[swankjesse]

So application code doesn’t need to do this:

    try {
      doTheThing()
    } catch (e: ConstraintViolationException) {
      throw ConflictException()
    } catch (e: RetryTransactionException) {
      when (Throwables.getRootCause(e)) {
        is ConstraintViolationException -> throw ConflictException()
        else -> throw e
      }
    } catch (e: javax.persistence.OptimisticLockException) {
      throw ConflictException()
    } catch (e: org.hibernate.OptimisticLockException) {
      throw ConflictException()
    }

[jjestrel]

closed by #1075

[ryanhall07]

does #1075 really close this? it just added mappers to turn exceptions into misk action responses. I think ideally the misk-hibernate apis expose an explicit set of Exceptions that can be thrown from Transacter operations, e.g ConstraintViolationException OptimiticLockException TimeoutException, etc.

We might even want to get rid of RetryTransactionException in favor of making retryable a property of the well defined exceptions

[jjestrel]

@ryanhall07 you want to wrap the hibernate exceptions in one more layer?

[ryanhall07]

@ryanhall07 you want to wrap the hibernate exceptions in one more layer?

well it's not really wrapping them in another layer, it's hiding them behind a well defined Transacter Exception API. I want to able to program against a Transacter api and not have to worry about the underlying hibernate exception details mess. The ExceptionMapper would then map Transacter Exceptions, not hibernate Exceptions to http response codes. In theory we would be able to completely swap out the hibernate impl of Transacter and everything would still work.