Re: DAO interfece question..Should interface throw Exceptions?

From:

Eric Sosman <esosman@acm-dot-org.invalid>

Newsgroups:

comp.lang.java.help

Date:

Tue, 20 Jun 2006 07:33:31 -0400

Message-ID:

<gIKdnahWV6iMQArZnZ2dnUVZ_u6dnZ2d@comcast.com>

dsh0105@gmail.com wrote:

I'm working on a fairly simple application that needs a simple data
access object. I've created an interface that describes the DAO, but my
problem is the SQLException.

My interface dosn't declare an SQLException to be thrown, but my
implementing class (just one right now) is backed by an SQL object and
could throw an Exception.

So my question is this:

Is it better to catch the SQL exception in the implenting methods and
throw a new unchecked exception, or is it better that the interface
allow implementing methods to throw an SQLException?

I lean towards throwing an unchecked Exception since it's possible --
if not likely, that an implementing class may not be backed by
something that throws and SQLException .

Is their a "best practice" for this situation?

A third possibility is to declare the method as throwing
a checked DAOException. The implementation can catch an
SQLException (or IOException or OneTimeException or ...) and
re-throw a DAOException that wraps it, using the original
exception as the "cause" of the wrapper.

I won't advise you about which approach to take, except to
parrot the usual wisdom that unchecked exceptions are typically
used when the caller isn't really expected to be able to do
anything constructive. Even though it's somewhat against the
spirit of encapsulation to think about how clients might use
your class someday, pondering a few "use cases" may give you
some ground for making a choice.

--
Eric Sosman
esosman@acm-dot-org.invalid