14

I know that in some version Hibernate exceptions were changed to be unchecked. what is the reason? is this a philosophy issue or practical one?

rogerdpack
  • 62,887
  • 36
  • 269
  • 388
oshai
  • 14,865
  • 26
  • 84
  • 140

1 Answers1

21

Practical. So you don't have to wrap every one of your operations regarding Hibernate in try catch blocks.

Taken from Java Persistence with Hibernate:

A history of exceptions — Exceptions and how they should be handled always end in heated debates between Java developers. It isn’t surprising that Hibernate has some noteworthy history as well. Until Hibernate 3.x, all exceptions thrown by Hibernate were checked exceptions, so every Hibernate API forced the developer to catch and handle exceptions. This strategy was influenced by JDBC , which also throws only checked exceptions. However, it soon became clear that this doesn’t make sense, because all exceptions thrown by Hibernate are fatal. In many cases, the best a developer can do in this situation is to clean up, display an error message, and exit the application. Therefore, starting with Hibernate 3.x, all exceptions thrown by Hibernate are subtypes of the unchecked Runtime Exception, which is usually handled in a single location in an application. This also makes any Hibernate template or wrapper API obsolete.

darioo
  • 46,442
  • 10
  • 75
  • 103
  • @T.J. yep, it would be good have it right here. I know I read this somewhere, so if I found that source, I'll post it here. – darioo Jan 05 '11 at 22:34
  • 2
    One of the many stupid decisions from Hibernate's staff. RuntimeExceptions are invisible if thrown inside a Thread: it only kills the Thread without any trace. RuntimeExceptions are forbidden in a library, this is very bad design. – Guillaume F. Dec 05 '15 at 21:10
  • Agreed. I now have to change all my classical try catches in the DAO layer and god knows where to RuntimeException. Imbeciles. – tggm Sep 21 '16 at 10:41