在c# 4.0中使用依赖注入时处理异常

本文关键字：注入 依赖 处理 异常 | 更新日期: 2023-09-27 18:14:03

首先，请原谅我的打字错误，因为英语不是我的母语。

假设我想在应用程序中使用构造函数注入。例如，我将写入如下内容:

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());
    }
}

如果我使用构造函数注入，根据定义，我没有控制也不知道实现IDataProvider的类的具体实例将被注入到我的DataReader类中。这意味着在我的DataReader类中，我不知道GetData方法中发生了什么，包括我不知道它是否会抛出异常，如果是的话，是什么样的异常。

在我的OutputData方法中，我应该把我的代码包装成一个try {} catch{}块，如果是这样，我应该捕获什么异常?如果我捕获IOException或SQLException或实际上任何类型的异常意味着我正在预先设想一些IDataProvider可能/应该实现的方式。我不认为它是好的。我还可以注入XMLDataProvider或NetworkResourceDataProvider。但与此同时，我必须在某些时候处理异常。

我的问题:处理异常和记录应用程序中发生的事情的正确方法是什么，一般使用控制反转和更具体的构造函数注入?此外，在实现接口的类中抛出异常的正确方法(如果有的话)是什么?

,

为我的问题添加精度，我将不拥有将实现IDataProvider的代码，因此我甚至不能确定自定义异常，例如DataProviderException将被抛出。

在c# 4.0中使用依赖注入时处理异常

根据定义，如果您不知道如何处理异常，那么就不要捕获它。时期。

在我看来，IDataProvider的具体实现应该捕获适当的异常(I/O for file provider, SQL for DB provider)，并引发另一个异常，该异常传达了获取数据的一般错误，即DataProviderException。如果需要，您可以将原始异常存储为内部异常属性，这样信息就不会丢失。

这样做，DataReader消费者只需要处理这个特定的异常，并且不受细节的影响。这假设消费者有一种处理异常的方法，即重试是可能的。

我想说的是，你的英语比我的法语好得多，所以我要"inquietes pas de ca"。

如果发生了SQLException，此时你不会在代码中做什么特别的事情，对吧?

一般来说，在知道如何处理异常之前，不希望捕获异常。异常通常为开发人员提供了一种了解哪里出了问题的方法:这就是为什么要使用堆栈跟踪。因此，通常最好让它们冒泡到UI下方的某个点，在那里你可以记录它们，并优雅地告诉用户发生了意想不到的事情。

相关文章：