Designing for jdbc and in-memory implementations

[dr_rod]

Can anyone reccomend an article or design pattern regarding interfaces with
different implementations and thus different integrity exceptions/concerns
per implementations?

For example a collection with a boolean isContained(Object) method. The
in-memory implementation is straightforward. But a jdbc implementation has
to handle a SQL Exception. What should it do? Pass true, false, or throw
the SQL Exception? If the latter, how would interface based usage of the
object be affected?

thanks!

[MarkN]

You should throw a custom Exception. You may return false if that is what
you mean (i.e. - 'Not found'). The concrete class should log the hidden
SQL exception.

Mark

"dr_rod" <AEG-Inc@hawaii.rr.com> wrote:
>
>Can anyone reccomend an article or design pattern regarding interfaces with
>different implementations and thus different integrity exceptions/concerns
>per implementations?
>
>For example a collection with a boolean isContained(Object) method. The
>in-memory implementation is straightforward. But a jdbc implementation
has
>to handle a SQL Exception. What should it do? Pass true, false, or throw
>the SQL Exception? If the latter, how would interface based usage of the
>object be affected?
>
>thanks!