07.11.2014 Views

Enterprise Library Test Guide - Willy .Net

Enterprise Library Test Guide - Willy .Net

Enterprise Library Test Guide - Willy .Net

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Test</strong>ing for Security Best Practices 149<br />

Table 36: Exception Management Checklist<br />

Check<br />

Yes<br />

Yes<br />

Yes<br />

Yes<br />

Description<br />

Use exception handling. Catch only the exceptions that you have anticipated in your<br />

design. Exceptions to this rule are exceptions that are not Common Language Specification<br />

(CLS)-compliant. (These are exceptions that do not derive from the .NET Framework<br />

System.Exception namespace.) These exceptions can occur if the application block<br />

uses a customer-supplied extension of if there is a call to unmanaged code. The application<br />

block should include a generic catch handler for these situations. (In C#, this<br />

takes the form of catch{ ... }). The inability to handle non-CLS-compliant exceptions may<br />

leave the application block vulnerable to denial of service attacks.<br />

An example of this situation is when the Data Access Application Block attempts to<br />

use a custom database class that is included in the configuration source. The following<br />

code example shows how to handle any non-CLS-compliant exceptions that may occur.<br />

private static void TryLogConfigurationError(ConfigurationErrorsException<br />

configurationException, string instanceName)<br />

{<br />

try<br />

{<br />

DefaultDataEventLogger eventLogger = <strong>Enterprise</strong><strong>Library</strong>Factory.BuildUp();<br />

if (eventLogger != null)<br />

{<br />

eventLogger.LogConfigurationError(configurationExcepti<br />

on, instanceName);<br />

}<br />

}<br />

catch { }<br />

}<br />

Log the details of the exceptions to assist in diagnosing problems.<br />

All code paths that can result in an exception should provide a way to first check for a<br />

successful outcome before throwing an exception. In the following code example, the<br />

code first checks to see that the configuration file exists and is valid before it throws an<br />

exception.<br />

Public FileConfigurationSource(string configurationFilepath)<br />

{<br />

if (string.IsNullOrEmpty(configurationFilepath)) throw new<br />

ArgumentException(Resources.ExceptionStringNullOrEmpty,<br />

"configurationFilepath");<br />

this.configurationFilepath =<br />

RootConfigurationFilePath(configurationFilepath);<br />

if (!File.Exists(this.configurationFilepath)) throw new<br />

FileNotFoundException(string.Format(Resources.Culture,<br />

Resources.ExceptionConfigurationLoadFileNotFound,<br />

this.configurationFilepath));<br />

EnsureImplementation(this.configurationFilepath);<br />

}<br />

If there is a problem, an exception should occur as early as possible to avoid needlessly<br />

using any more resources.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!