Exception Handling Dilemma
-
My debugger breaks for the below exception when trying to restore a database, because the database is in use. My question is, if I don't catch exceptions in my
DatabaseHelperclass, following what I believe to be good practice, then I should at least catch and publish the exception in clients ofDatabaseHelper. However, these clients should know nothing of thisFailedOperationExceptionexception, so to catch it I would have to broaden my catch scope, which I believe is not good practice. What do I do?Microsoft.SqlServer.Management.Smo.SmoExceptionType.FailedOperationException -
My debugger breaks for the below exception when trying to restore a database, because the database is in use. My question is, if I don't catch exceptions in my
DatabaseHelperclass, following what I believe to be good practice, then I should at least catch and publish the exception in clients ofDatabaseHelper. However, these clients should know nothing of thisFailedOperationExceptionexception, so to catch it I would have to broaden my catch scope, which I believe is not good practice. What do I do?Microsoft.SqlServer.Management.Smo.SmoExceptionType.FailedOperationExceptionYou catch this in your database class. This is a specific database related problem - I would then throw this as a custom exception to the client applications, with details of this as the inner exception.
Deja View - the feeling that you've seen this post before.
-
You catch this in your database class. This is a specific database related problem - I would then throw this as a custom exception to the client applications, with details of this as the inner exception.
Deja View - the feeling that you've seen this post before.
This is for a testing framework, so would you minimise custom exceptions and use one for multiple helper classes, or go with a tighter fit of one custom exception per helper class? Also, I use DatabaseHelper in SelectionHelper, so using only one custom exception reduces the complexity of Russian Doll type exceptions. In SelectionHelper I wrap CLR exceptions, and just re-throw custom exceptions.
-
This is for a testing framework, so would you minimise custom exceptions and use one for multiple helper classes, or go with a tighter fit of one custom exception per helper class? Also, I use DatabaseHelper in SelectionHelper, so using only one custom exception reduces the complexity of Russian Doll type exceptions. In SelectionHelper I wrap CLR exceptions, and just re-throw custom exceptions.
We tend to use exceptions based on logical areas.
Deja View - the feeling that you've seen this post before.