Frank,
> Other than overloading the function for each type (which kind of defeats
the
> purpose of having a single function to handle data related exceptions),
can
> anyone suggest anything?
Create proxy objects (Adapter Pattern really) for each type of exception
(Data Source), that your single function can then use to access the errors
collection & error objects, generically.
Alternatively create n+1 routines. One for each of the specific exception
classes, then the +1 that the previous n call passing the errors collection,
generically.
In both of the above, read generically as ICollection or IEnumerable, and
methods found on Object (ToString for example).
I think the proxy objects may be the 'easier' route, as the various errors
collections contain objects of different types. If those objects honor
..ToString, this should be easy, otherwise...
Hope this helps
Jay
"Frank Rizzo" <(E-Mail Removed)> wrote in message
news:uKWtGf$(E-Mail Removed)...
> I have an app that has to connect to various data sources (ms sql server,
> sybase, etc...). For this reason I have OdbcConnection, OleDb Connection
and
> SqlClient objects. When an error happens, I want a single procedure to
> handle the error from all the connection types by passing the either the
> SqlException, OdbcException or OleDbException.
>
> Unfortunately the object SystemException, that these exceptions have been
> derived from, does not have the .Errors collection (like the SqlException,
> OdbcException or OleDbException does), so when I pass SystemException into
> the procedure and attempt to loop through the Errors collection, it
> obviously complains that SystemException does not have such a collection.
>
> Other than overloading the function for each type (which kind of defeats
the
> purpose of having a single function to handle data related exceptions),
can
> anyone suggest anything?
>
> --
> Frank
>
>
|
Similar Threads
