I have done things like retry logic and/or switching to a different database in a cluster -- but at all costs I try to do that at the driver level (with a driver proxy class), rather than in the business logic. But even if I did it in the business logic, while I might catch the exception for the retry, I would not distinguish the failure.
This is really rare though, and I can't remember the last time I did it. Currently where I work they do the cluster failover logic in a driver proxy as I mentioned. Cheers, Clinton On Fri, Dec 4, 2009 at 10:27 AM, Rick.Wellman <[email protected]>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:[email protected]] > *Sent:* Thursday, December 03, 2009 7:47 PM > *To:* [email protected] > *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 <[email protected]> > 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: [email protected] > For additional commands, e-mail: [email protected] > > >
