Exception handling when using dependency injection in C # 4.0

Question

First of all, please excuse any typo, since English is not my first language.

Let's say I want to use constructor injection in my application. So, for example, I will have something like this:

public class FileDataProvider : IDataProvider { public MyData GetData() { // Get data from a file } } public class DatabaseDataProvider : IDataProvider { public MyData GetData() { // Get data from a database } } public class DataReader : IDataReader { private IDataProvider dataProvider; public DataReader(IDataProvider dataProvider) { this.dataProvider = dataProvider; } public void OutputData() { MyData data = dataProvider.GetData(); Console.WriteLine("{0}", data.ToString()); } } 

If I use constructor injection, by definition I do not control and do not represent a specific instance of the class that implements IDataProvider, which will be introduced into my DataReader class. This means that in my DataReader class, I don’t know what is going on in the GetData method, including the fact that I don’t know if it can throw an exception or not, and if so, which exception.

In my OutputData method, I have to wrap my code in a try {} catch {} block, and if so, what exception should I catch? If I catch an IOException or SQLException or actually some exception, then I anticipate some of the ways that IDataProvider can / should be implemented. I do not think this is good. I could also use XMLDataProvider or NetworkResourceDataProvider. But at the same time, I have to handle exceptions at some point.

My question is: What is the correct way to handle exceptions and register what is happening in the application, using inversion of control in general and installing the constructor more specifically? And what is the right way - if any - to throw exceptions in the class that implements the interface?

-

Adding accuracy to my question, I will not have code that will implement IDataProvider, so I can’t even be sure that a custom exception will be thrown, such as a DataProviderException . Even if I write recommendations for developers to do this ...

Answer 1

In my opinion, specific implementations of IDataProvider should catch the corresponding exceptions (input-output for file povider, SQL for the database provider) and create another exception that associates a general error with receiving data, i.e. a DataProviderException . If necessary, you can save the original exception as an internal property of the exception so that information is not lost.

Therefore, the DataReader consumer must handle this particular exception and be protected from detail. This assumes that the consumer has a way to handle the exception, i.e. Repeatable.

Answer 2

By definition, if you do not know how to handle an exception, then do not understand it. Period.

Answer 3

Let me start by saying that your English is better than my French, so t'inquietes pas de ca.

You are not going to do anything special at this point in the code if an SQLException occurs, right?

In general, you do not want to catch the exception until you know what to do with it. Exceptions usually give developers the opportunity to find out what went wrong: why do you get a stack trace to go along with them. Thus, it is usually best to let them bounce to a point below the user interface where you can register them and elegantly tell the user that something unexpected has happened.