我应该如何防守?

我正在使用一个用于创build数据库连接的小例程:

之前

public DbConnection GetConnection(String connectionName) { ConnectionStringSettings cs= ConfigurationManager.ConnectionStrings[connectionName]; DbProviderFactory factory = DbProviderFactories.GetFactory(cs.ProviderName); DbConnection conn = factory.CreateConnection(); conn.ConnectionString = cs.ConnectionString; conn.Open(); return conn; } 

然后我开始研究.NET框架文档,查看各种事情的logging行为,看看我能否处理它们。

例如:

 ConfigurationManager.ConnectionStrings... 

该文件说,如果ConnectionStrings无法检索集合,则会调用ConfigurationErrorException 。 在这种情况下,我无法处理这个exception,所以我会放手。


下一部分是ConnectionStrings的实际索引来查找connectionName

 ...ConnectionStrings[connectionName]; 

在这种情况下ConnectionStrings文档说,如果无法find连接名称,该属性将返回null 。 我可以检查发生这种情况,并抛出一个exception,让高人,他们给了一个无效的connectionName:

 ConnectionStringSettings cs= ConfigurationManager.ConnectionStrings[connectionName]; if (cs == null) throw new ArgumentException("Could not find connection string \""+connectionName+"\""); 

我重复同样的练习:

 DbProviderFactory factory = DbProviderFactories.GetFactory(cs.ProviderName); 

如果找不到指定ProviderName的工厂, GetFactory方法没有文档。 它没有logging返回null ,但我仍然可以防守,并检查为空:

 DbProviderFactory factory = DbProviderFactories.GetFactory(cs.ProviderName); if (factory == null) throw new Exception("Could not obtain factory for provider \""+cs.ProviderName+"\""); 

接下来是DbConnection对象的构造:

 DbConnection conn = factory.CreateConnection() 

再次, 文档没有说如果它不能创build一个连接会发生什么,但我可以再次检查一个空返回对象:

 DbConnection conn = factory.CreateConnection() if (conn == null) throw new Exception.Create("Connection factory did not return a connection object"); 

接下来是设置Connection对象的属性:

 conn.ConnectionString = cs.ConnectionString; 

文档不会说如果无法设置连接string会发生什么情况。 它是否抛出exception? 它忽略了吗? 与大多数例外情况一样,如果在尝试设置连接的ConnectionString时出现错误,我无法从中恢复。 所以我什么都不做


最后,打开数据库连接:

 conn.Open(); 

DbConnection的Open方法是抽象的,所以它取决于从DbConnection递减的任何提供者来决定它们抛出的exception。 在抽象Open方法文档中也没有关于如果出现错误可以期望发生的事情的指导。 如果有错误连接,我知道我无法处理它 – 我不得不让它冒出来的地方,呼叫者可以显示一些用户界面,让他们再试一次。


 public DbConnection GetConnection(String connectionName) { //Get the connection string info from web.config ConnectionStringSettings cs= ConfigurationManager.ConnectionStrings[connectionName]; //documented to return null if it couldn't be found if (cs == null) throw new ArgumentException("Could not find connection string \""+connectionName+"\""); //Get the factory for the given provider (eg "System.Data.SqlClient") DbProviderFactory factory = DbProviderFactories.GetFactory(cs.ProviderName); //Undefined behaviour if GetFactory couldn't find a provider. //Defensive test for null factory anyway if (factory == null) throw new Exception("Could not obtain factory for provider \""+cs.ProviderName+"\""); //Have the factory give us the right connection object DbConnection conn = factory.CreateConnection(); //Undefined behaviour if CreateConnection failed //Defensive test for null connection anyway if (conn == null) throw new Exception("Could not obtain connection from factory"); //Knowing the connection string, open the connection conn.ConnectionString = cs.ConnectionString; conn.Open() return conn; } 

概要

所以我的四行函数变成了12行,需要5分钟的文档查找。 最后,我确实捕获了一个方法允许返回null的情况。 但在实践中,我所做的只是将访问冲突exception(如果我试图对空引用调用方法)转换为InvalidArgumentExceptionexception。

我也抓住两个可能的情况下,可能是返回对象; 但是我又一次只交易了一个例外。

从积极的方面来说,它确实遇到了两个问题,并解释了例外消息中发生的事情,而不是发生在路上的坏事情(即,在这里降压)

但是这值得吗? 这是否过度杀伤? 这个防守编程是错误的吗?

手动检查configuration并抛出一个exception并不比只是在丢失configuration时让框架抛出exception更好。 你只是复制在框架方法内部发生的先决条件检查,它使你编码冗长,没有任何好处。 (实际上,你可能会把所有的东西都作为基类的Exception类去除 ,框架抛出的exception通常更具体。)

编辑:这个答案似乎有点争议,所以一点阐述:防御性编程意味着“准备意外”(或“是偏执狂”),其中一个方法是做很多先决条件检查。 在许多情况下,这是一个很好的做法,但是所有的做法都应该权衡成本。

例如,它没有提供任何好处来抛出“无法从工厂获取连接”exception,因为它没有提供任何关于为什么无法获取提供者的信息 – 而且下一行将抛出一个exception,无论如何提供程序为空。 所以前提条件检查的成本(开发时间和代码复杂度)是不合理的。

另一方面,validation连接stringconfiguration是否存在的检查可能是合理的,因为例外可以帮助告诉开发者如​​何解决问题。 无论如何,你将在下一行得到的空例外不会告诉缺less连接string的名称,所以你的前提条件检查确实提供了一些价值。 例如,如果代码是组件的一部分,则该值非常大,因为组件的用户可能不知道组件需要哪些configuration。

防御性编程的一个不同的解释是,你不应该只是检测错误条件,你应该尝试从任何可能发生的错误或exception中恢复。 我不认为这是一个好主意。

基本上你应该只处理你可以做的事情。 无论如何,您无法恢复的exception应该向上传递给顶层处理程序。 在Web应用程序中,顶层处理程序可能只是显示一个通用的错误页面。 但是在大多数情况下,如果数据库处于脱机状态或缺less一些重要的configuration,则不需要做太多的事情。

有些情况下,这种防御性编程是有道理的,如果你接受用户input,而且input可能导致错误。 例如,如果用户提供了一个URL作为input,并且应用程序试图从该URL获取某些内容,那么检查该URL看起来是否正确并且处理可能来自该请求的任何exception是非常重要的。 这使您可以向用户提供有价值的反馈。

那么,这取决于你的观众是谁。

如果你正在编写你希望被许多其他人使用的库代码,谁也不会和你谈论如何使用它,那么这不是一个过度的技巧。 他们会感激你的努力。

(也就是说,如果你这样做了,我build议你定义比System.Exception更好的exception,以便让那些想要捕获你的exception而不是其他exception的人更容易。

但是如果你只是要自己使用它(或者你和你的好友),那显然是过度的,最后可能会让你的代码变得不可读。

我希望能让我的团队像这样编码。 大多数人甚至没有得到防守编程的点。 他们所做的最好的做法是将整个方法包装在一个try catch语句中,并让所有exception由genericsexception块处理!

给你的帽子伊恩。 我可以理解你的困境。 我自己也一样。 但是,你做了什么可能帮助了一些开发人员几个小时的键盘打击。

记住,当你使用.net框架API时,你期望什么呢? 什么似乎很自然? 对你的代码做同样的事情。

我知道这需要时间。 但质量是有代价的。

PS:你真的不必处理所有的错误,并抛出一个自定义的exception。 请记住,您的方法将只被其他开发人员使用。 他们应该能够自己找出共同的框架例外。 这是不值得的麻烦。

你的“之前”的例子有明确和简洁的区别。

如果有什么错误,框架最终会抛出一个exception。 如果你不能对exception做任何事情,你可以让它传播到调用堆栈。

然而,有时候,在框架内部抛出一个exception,并不能说明实际的问题。 如果你的问题是你没有一个有效的连接string,但是框架会抛出一个exception,例如“invalid use of null”,那么有时候最好是捕捉exception并用更有意义的消息重新抛出exception。

我会检查空对象很多,因为我需要一个实际的对象来操作,如果对象是空的,抛出的exception将倾斜,至less可以说。 但是我只检查空对象,如果我知道会发生什么。 一些对象工厂不返回空对象; 他们会抛出exception,而在这些情况下检查null将是无用的。

我不认为我会写任何空引用检查逻辑 – 至less,而不是你已经做到这一点。

从应用程序configuration文件中获取configuration设置的程序将在启动时检查所有这些设置。 我通常构build一个静态类来包含设置,并在应用程序的其他地方引用该类的属性(而不是ConfigurationManager )。 有两个原因。

首先,如果应用程序没有正确configuration,就不会起作用。 当我尝试创build数据库连接时,我宁愿知道程序读取configuration文件的时刻。

其次,检查configuration的有效性不应该是依赖于configuration的对象的关注。 如果您已经在前面执行了这些检查,那么在您的代码中无处不在插入检查是没有意义的。 (当然也有例外,例如,长时间运行的应用程序需要在程序运行时更改configuration,并将这些更改反映在程序的行为中;在这样的程序中,您需要只要需要设置,就进入ConfigurationManager 。)

我也不会对GetFactoryCreateConnection调用进行空引用检查。 你将如何编写一个testing用例来运行该代码? 你不能,因为你不知道如何使这些方法返回null – 你甚至不知道有可能使这些方法返回null。 所以你已经replace了一个问题 – 你的程序可以在你不明白的条件下抛出一个NullReferenceException ,另一个更重要的问题是:在那些相同的神秘的条件下,你的程序会运行你没有testing过的代码。

您的方法文档丢失。 😉

每种方法都有一些定义的input和输出参数以及一个定义的结果行为。 在你的情况下是这样的:“如果成功返回有效的开放连接,否则返回null(或者抛出一个XXXException,如你所愿)。记住这个行为,你现在可以决定如何防御编程。

  • 如果你的方法应该公开详细的信息为什么和什么是失败的,那么像你一样做,检查和抓住所有的一切,并返回相应的信息。

  • 但是,如果您只是对打开的DBConnection感兴趣,或者对失败只是null (或某个用户​​定义的exception),那么只需将所有内容包装在try / catch中,并返回null (或某种exception),而其他对象则返回null

所以我会说,这取决于方法的行为和预期的输出。

一般来说,特定于数据库的exception应该被捕获并重新抛出,比如(假设的) DataAccessFailureexception。 在大多数情况下,高级代码不需要知道您正在从数据库中读取数据。

快速捕获这些错误的另一个原因是,他们经常在消息中包含一些数据库详细信息,如“没有这样的表:ACCOUNTS_BLOCKED”或“用户密钥无效:234234”。 如果这种情况传播给最终用户,这在几个方面是不好的:

  1. 扑朔迷离
  2. 潜在的安全漏洞
  3. 尴尬为贵公司的形象(想象一个客户阅读错误信息粗糙的语法)

我的经验法则是:

如果抛出exception的消息与调用者相关,则不捕获。

因此,NullReferenceException没有相关的消息,我会检查它是否为空,并抛出一个更好的消息的exception。 ConfigurationErrorException是相关的,所以我不理解它。

唯一的例外是如果GetConnection的“契约”不必检索configuration文件中的连接string。

如果是这种情况GetConnection应该有一个自定义的exception,说连接无法检索,那么你可以包装ConfigurationErrorException在你的自定义exception。

另一个解决scheme是指定GetConnection不能抛出(但可以返回null),然后给你的类添加一个“ExceptionHandler”。

我会编写它就像你第一次尝试。

但是,该函数的用户将使用USING块来保护连接对象。

我真的不喜欢翻译像其他版本的exception,因为它很难找出为什么它打破了(数据库closures?没有权限读取configuration文件等)。

修改后的版本并没有增加太多的价值,只要应用程序有一个AppDomain.UnexpectedException处理程序将exception.InnerException链接和所有堆栈跟踪转储到某种日志文件(甚至更好,捕获一个小型转储),然后调用Environment.FailFast

从这些信息中可以明确地发现问题出在哪里,而不需要通过额外的错误检查来复杂化方法代码。

请注意,最好处理AppDomain.UnexpectedException并调用Environment.FailFast而不是使用顶级try/catch (Exception x)因为对于后者,问题的原因可能会被进一步的exception所遮蔽。

这是因为如果你捕捉到一个exception,任何打开的finally块都会执行,并且可能会抛出更多的exception,这将会隐藏原来的exception(或者更糟糕的是,它们会删除文件,试图恢复某些状态,可能是错误的文件,甚至可能是重要的文件)。 你不应该捕获一个exception,指出你不知道如何处理的一个无效的程序状态 – 即使在顶级main函数try/catch块中。 处理AppDomain.UnexpectedException并调用Environment.FailFast是一个不同的(也是更理想的)水壶,因为它finally阻止了运行,如果你试图停止你的程序并logging一些有用的信息而不会造成进一步的损害,绝对不想运行你的finally块。

不要忘记检查OutOfMemoryExceptions …你知道,它可能会发生。

伊恩的变化对我来说很明智。

如果我正在使用一个系统,并且使用不当,我想获得有关误用的最大信息。 例如,如果我忘记在调用方法之前将一些值插入到configuration中,我想要一个InvalidOperationException,其中包含详细描述我的错误的消息,而不是KeyNotFoundException / NullReferenceException。

这一切都是关于国际海事组织。 在我这个时代,我已经看到了一些相当难以理解的exception消息,但是其他时候来自框架的默认exception是完全正确的。

一般来说,我认为最好谨慎一点,特别是当你写的东西被其他人大量使用的时候,或者在错误难以诊断的调用图中。

我总是试着记住,作为一个代码或系统的开发者,我比一个正在使用它的人更能够诊断故障。 有时候,几行检查代码+一个自定义的exception消息可以累积地节省几个小时的debugging时间(同时也让你自己的生活更轻松,因为你不会被拖到别人的机器去debugging他们的问题)。

在我眼中,你的“之后”样本并不是真正的防御。 因为防御是检查你的控制下的部分,这将是参数connectionName (检查null或空,并引发ArgumentNullException)。

在添加所有防御性编程之后,为什么不把你拥有的方法分开? 你有一堆不同的逻辑块,保证单独的方法。 为什么? 因为那么你封装了属于一起的逻辑,你所得到的公共方法只是以正确的方式连接这些块。

像这样的东西(编辑SO编辑器,所以没有语法/编译器检查,可能不会编译;-))

 private string GetConnectionString(String connectionName) { //Get the connection string info from web.config ConnectionStringSettings cs= ConfigurationManager.ConnectionStrings[connectionName]; //documented to return null if it couldn't be found if (cs == null) throw new ArgumentException("Could not find connection string \""+connectionName+"\""); return cs; } private DbProviderFactory GetFactory(String ProviderName) { //Get the factory for the given provider (eg "System.Data.SqlClient") DbProviderFactory factory = DbProviderFactories.GetFactory(ProviderName); //Undefined behaviour if GetFactory couldn't find a provider. //Defensive test for null factory anyway if (factory == null) throw new Exception("Could not obtain factory for provider \""+ProviderName+"\""); return factory; } public DbConnection GetConnection(String connectionName) { //Get the connection string info from web.config ConnectionStringSettings cs = GetConnectionString(connectionName); //Get the factory for the given provider (eg "System.Data.SqlClient") DbProviderFactory factory = GetFactory(cs.ProviderName); //Have the factory give us the right connection object DbConnection conn = factory.CreateConnection(); //Undefined behaviour if CreateConnection failed //Defensive test for null connection anyway if (conn == null) throw new Exception("Could not obtain connection from factory"); //Knowing the connection string, open the connection conn.ConnectionString = cs.ConnectionString; conn.Open() return conn; } 

PS:这不是一个完整的重构,只有前两个块。