I want to instantiate an OleDbException

[Guest]

I want to do something like:

catch ( System.Data.OleDb.OleDbException err )
{
throw ( new System.Data.OleDb.OleDbException ( "something
application-specific" , err ) ) ;
}

But the constructoris not public (it seems).

Is there a work-around other than using System.Exception (which isn't
appropriate)?

I suppose deriving my own Exception is the best practice, so I'll do that,
but I don't think that the framework should enforce it. And I see now that
OleDbException is sealed, so I need to derive from
System.Data.Common.DbException which is, again, not quite what I want.

Perhaps if the goal is to help newbies find the best practice, the
constructor should be public but obsoleted and have the compiler display text
to point the newbie in the right direction.

 

[Teemu Keiski]

Hi,

the way it's been thought indeed is that, you'd derive your own Exception
class, and place the original OleDbException as inner exception. That is, if
you can provide additional information up the call hierarchy (and there can
be done something meaningful with the exception).

If you can't add any info and cannot do anything useful for it here, you
shouldn't even catch it I suppose that OleDbException is sealed because it
provides all what it comes to exceptional situations with OleDb. What you'd
be adding would be additional to that and not OleDb related, actually.
Therefore, it might not be meaningful to derive from OleDbException.

Besides, if there's case where you'd need to catch exceptions, you couldn't
make difference between your own exception situations and OleDb's internal
ones, if you don't have your own exception, which might actually be quite
important. For example you might want to show user-friendly msgs with your
custom exception class.

 

[Guest]

Well, particularly with DB routines, I want to add in the CommandText that
was being executed, and some higher-level explanation of what was being done.
But it remains that the actual problem should be an OleDbException.

On the other hand, some developers may want to derive from DbException to
have a more generic handler of exceptions from the various engines available.

Or perhaps catch should be able to scan InnerExceptions, to some specified
level.