The code, exception-wise, makes no sense at all, that's why. First of all, you define the exception class
databasetypeException
, but never throw an instance of it. The method
catchException
make no sense, it does not catch anything, only throws some exception of unrelated type
System.Exception
. No wonder: methods catching exceptions make no sense, because you have to use some try-catch blocks anyway. (At the same time, methods
handling some exceptions do make sense.) Anyway, you never call this method.
You have only one try-catch block. Most likely, you catch the exception too locally. Usually, exceptions are caught in very few, strategically chosen parts of code; in most cases, you just let them go (
propagate) from the current stack frame, far from the stack frame of throwing it. But I cannot blame you for doing it wrong, because I understand you are doing some study, which is good.
I tried to quickly explain this mechanism ("time machine") in my past answers:
Does Exception in C# Constructor Cause Caller Assignment to Fail?[
^],
where was stored .net exceptions in operating system[
^].
In effect, the idea is to highly isolate "normal" instruction flow from exceptional processing. It helps you to forget about most exceptional cases (including, but not limited to errors) in most of your development cycle.
What else? Traditionally, application-specific exceptions like yours should be derived from
System.ApplicationException
, not from
System.Exception
. This is not a big problem, just a matter of neat style of the design of your code, and supportability.
—SA