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



Eric,

Thanks! I think the DAOException you suggest is probably a good idea.
It seems likely that most implementations will be backed by something
that coud throw a checked Exception and since their is something the
client could potentially do to fix the problem (like looking elsewhere
for a missing file) a checked Exception seems to be a good fit.

David



Eric Sosman wrote:
dsh0105@xxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx

.



Relevant Pages

  • Re: SqlException deserialization
    ... InitialCatalog are invalid so a login exception is thrown. ... The stacktrace before serialisation is: ... > without deserialization). ... >> soapformatter and then deserialize and the resulting SqlException has ...
    (microsoft.public.dotnet.framework.adonet)
  • Sqlexception serialization/deserialization
    ... I'm having a problem with a SqlException that I am serializing and ... is a sql exception with the following message: ... StackTrace property. ... soapformatter and then deserialize and the resulting SqlException has ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: wtf?
    ... > called by the ASP classic app, ... >> other than error translation. ... > exception that comes from the command's execute method doesn't seem to ... > the time we might be content saying "SqlException", in this case, we ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: size of a sizeof(pointer)
    ... Most C implementations do not check pointer validity. ... I feel that is a significant exception to. ... I've studied structural linguistics, socio- ... So C's use of 128-bit pointers didn't have ...
    (comp.lang.c)
  • Re: a criticism of java
    ... > a)Integer.parseInt was one of the method that got up my nose. ... catch (final Exception exception) ... IOException and a NumberFormatException with it, ... SQLException, and just logging it. ...
    (comp.lang.java.programmer)