We have a custom db connection pool which checks error codes/sql states on the SQLException and determines whether a reconnect is necessary (cheaper than running a validation query). But this happens behind the scenes and not on the business layer.
Spring's DataAccessException hierarchy also works on checking vendor specific codes and translating those into useful vendor neutral exceptions for things like a duplicate record inserted or deadlock. I have also come to dislike checked exceptions... Zach On Fri, 4 Dec 2009 11:27:26 -0600 Rick.Wellman <rick.well...@kiewit.com> wrote: > Agreed on both points below... but am curious to the community at > large... has anyone come up with something useful to do on a database > exception other than apologize to the user? This might be a good forum > to share. > > > > From: Clinton Begin [mailto:clinton.be...@gmail.com] > Sent: Thursday, December 03, 2009 7:47 PM > To: user-java@ibatis.apache.org > Subject: Re: IBatis 3 Exceptions > > > > Nope. Nothing technical. I just happen to hate checked exceptions. > :-) > > The original exception is always nested within the runtime one though, > so you have full access to everything you need. > > There is a bit of placeholder code where I had intended to build a > hierarchy of exceptions, similar to Spring's exceptions. But honestly, > I cannot recall a time in my 12 years of Java coding when I could > actually do something useful with a database exception, other than > apologize to the user with a dialog box. > > Clinton > > On Thu, Dec 3, 2009 at 2:15 PM, Alex Sherwin > <alex.sher...@acadiasoft.com> wrote: > > Why does IBatis 3.0 throw IbatisException (RuntimeException) instead of > checked exceptions? > > Is this a limitation now due to the dynamic nature of the generic typed > mapped statement classes? IbatisException doesn't even seem to wrap > SQLException, I see it wrapping the native exceptions from my JDBC > driver (MySQL). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org > For additional commands, e-mail: user-java-h...@ibatis.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org For additional commands, e-mail: user-java-h...@ibatis.apache.org