Archive

Archive for May, 2008

Preventing SQL injection attacks in ASP.NET

May 30, 2008 1 comment

Consider a simple web application that requires user input in some fields, lets say some search box. Suppose a user types the following string in that textbox:

'; DROP DATABASE pubs --

On submit our application executes the following dynamic SQL statement

SqlDataAdapter myCommand = new SqlDataAdapter("SELECT OrderId, OrderNumber FROM Orders WHERE OrderNumber = '" + OrderNumberTextBox.Text + "'", myConnection);

Or stored procedure

SqlDataAdapter myCommand = new SqlDataAdapter("uspGetOrderList '" + OrderNumberTextBox.Text + "'", myConnection);

The intention being that the user input would be run as

SELECT OrderId, OrderNumber FROM Orders WHERE OrderNumber = 'PO123'

However, the code inserts the user’s malicious input and generates the following query.

SELECT OrderId, OrderNumber FROM Orders WHERE OrderNumber = ''; DROP DATABASE pubs --'

In this case, the ‘ (single quotation mark) character that starts the rogue input terminates the current string literal in the SQL statement. As a result, the opening single quotation mark character of the rogue input results in the following statement.

SELECT OrderId, OrderNumber FROM Orders WHERE OrderNumber = ''

The; (semicolon) character tells SQL that this is the end of the current statement, which is then followed by the following malicious SQL code.

; DROP DATABASE pubs

Finally, the — (double dash) sequence of characters is a SQL comment that tells SQL to ignore the rest of the text. In this case, SQL ignores the closing ‘ (single quotation mark) character, which would otherwise cause a SQL parser error.

--'

Using stored procedures doesn’t solve the problem either because the generated query would be

uspGetOrderList ''; DROP DATABASE pubs--'

Or perhaps this was your login page and your query being

SELECT UserId FROM Users WHERE LoginId = <inputlogin> AND Password = <inputpwd> AND IsActive = 1

Someone could easily login by typing in the following in your login textbox

' OR 1 = 1; --

Which makes our query

SELECT UserId FROM Users WHERE LoginId = '' OR 1 = 1; --' AND Password = '' AND IsActive = 1

Viola, the attacker has now successfully logged in to your site using SQL injection attack.

SQL injection can occur, as demonstrated above, when an application uses input to construct dynamic SQL statements or when it uses stored procedures to connect to the database. Conventional security measures, such as the use of SSL and IPSec, do not protect your application from SQL injection attacks. Successful SQL injection attacks enable malicious users to execute commands in an application’s database. Common vulnerabilities that make your data access code susceptible to SQL injection attacks include:

  • Weak input validation.
  • Dynamic construction of SQL statements without the use of type-safe parameters.
  • Use of over-privileged database logins.

    So what can we do to help protect our application from such attacks? To counter SQL injection attacks, we need to:

  • Constrain and sanitize input data

    Check for known good data by validating for type, length, format, and range and using a list of acceptable characters to constrain input. Create a list of acceptable characters and use regular expressions to reject any characters that are not on the list. Using the list of unacceptable characters is impractical because it is very difficult to anticipate all possible variations of bad input.

    Start by constraining input in the server-side code for your ASP.NET Web pages. Do not rely on client-side validation because it can be easily bypassed. Use client-side validation only to reduce round trips and to improve the user experience. Check my other blog on Validation Application Block for server-side validation.

    If in the previous code example, the Order Number value is captured by an ASP.NET TextBox control, you can constrain its input by using a RegularExpressionValidator control as shown in the following.

    <%@ language="C#" %> <form id="form1" runat="server"> <asp:TextBox ID="OrderNumberTextBox" runat="server"/> <asp:RegularExpressionValidator ID="regexpPO" runat="server" ErrorMessage="Incorrect Order Number" ControlToValidate="OrderNumberTextBox" ValidationExpression="^PO\d{3}-\d{2}$" /> </form>

    If the Order Number input is from another source, such as an HTML control, a query string parameter, or a cookie, you can constrain it by using the Regex class from the System.Text.RegularExpressions namespace. The following example assumes that the input is obtained from a cookie.

    using System.Text.RegularExpressions; if (Regex.IsMatch(Request.Cookies["OrderNumber"], "^PO\d{3}-\d{2}$")) { // access the database } else { // handle the bad input }

    Performing input validation is essential because almost all application-level attacks contain malicious input. You should validate all input, including form fields, query string parameters, and cookies to protect your application against malicious command injection. Assume all input to your Web application is malicious, and make sure that you use server validation for all sources of input. Use client-side validation to reduce round trips to the server and to improve the user experience, but do not rely on it because it is easily bypassed.

     

  • Apply ASP.NET request validation during development to identify injection attacks

    ASP.NET request validation detects any HTML elements and reserved characters in data posted to the server. This helps prevent users from inserting script into your application. Request validation checks all input data against a hard-coded list of potentially dangerous values. If a match occurs, it throws an exception of type HttpRequestValidationException.

    Request validation is enabled by ASP.NET by default. You can see the following default setting in the Machine.config.comments file.

    <pages validateRequest="true" ... />

    Confirm that you have not disabled request validation by overriding the default settings in your server’s Machine.config file or your application’s Web.config file.

    You can disable request validation in your Web.config application configuration file by adding a <pages> element with validateRequest="false" or on an individual page by setting ValidateRequest="false" on the @ Pages element.

    NOTE: You should disable Request Validation only on the page with a free-format text field that accepts HTML-formatted input.

    You can test the effects of request validation. To do this, create an ASP.NET page that disables request validation by setting ValidateRequest="false", as follows.

    <%@ Language="C#" ValidateRequest="false" %> <html> <script runat="server"> void btnSubmit_Click(Object sender, EventArgs e) { // If ValidateRequest is false, then 'hello' is displayed // If ValidateRequest is true, then ASP.NET returns an exception Response.Write(txtString.Text); } </script> <body> <form id="form1" runat="server"> <asp:TextBox id="txtString" runat="server" Text="<script>alert('hello');</script>" /> <asp:Button id="btnSubmit" runat="server" OnClick="btnSubmit_Click" Text="Submit" /> </form> </body> </html>

    When you run the page, "Hello" is displayed in a message box because the script in txtString is passed through and rendered as client-side script in your browser.

    If you set ValidateRequest="true" or remove the ValidateRequest page attribute, ASP.NET request validation rejects the script input and produces an error similar to the following.

    A potentially dangerous Request.Form value was detected from the client (txtString="<script>alert(‘hello…").
    Note   Do not rely on ASP.NET request validation. Treat it as an extra precautionary measure in addition to your own input validation.

  • Constrain input by using validator controls

    To constrain input, use server-side input validation. Do not rely on client-side validation because it is easily bypassed. Use client-side validation in addition to server-side validation to reduce round trips to the server and to improve the user experience. Validate length, range, format and type. Make sure that any input meets your guidelines for known good input.

    Use the ASP.NET validator controls to constrain form field input received through server controls. For other sources of input data, such as query strings, cookies, and HTTP headers, constrain input by using the Regex class from the System.Text.RegularExpressions namespace. Or you can use the Enterprise Library Validation Application Block to check for input validation. The Validation Application Block can not be used for input validation but it can also validate your business objects. See my other blog on Validation Application Block.

  • Encode unsafe output

    If your application needs to accept a range of HTML elements—for example through a rich text input field such as a comments field—turn off ASP.NET request validation and create a filter that allows only the HTML elements that you want your application to accept. A common practice is to restrict formatting to safe HTML elements such as <b> (bold) and <i> (italic). Before writing the data, HTML-encode it. This makes any malicious script safe by causing it to be handled as text, not as executable code.

    The HtmlEncode method replaces characters that have special meaning in HTML to HTML variables that represent those characters. For example, < is replaced with &lt; and " is replaced with &quot;. Encoded data does not cause the browser to execute code. Instead, the data is rendered as harmless text, and the tags are not interpreted as HTML.

    The following page disables ASP.NET request validation by setting ValidateRequest="false". It HTML-encodes the input and selectively allows the <b> and <i> HTML elements to support simple text formatting.

    <%@ Page Language="C#" ValidateRequest="false"%> <script runat="server"> void submitBtn_Click(object sender, EventArgs e) { // Encode the string input StringBuilder sb = new StringBuilder( HttpUtility.HtmlEncode(htmlInputTxt.Text)); // Selectively allow and <i> sb.Replace("&lt;b&gt;", "<b>"); sb.Replace("&lt;/b&gt;", ""); sb.Replace("&lt;i&gt;", "<i>"); sb.Replace("&lt;/i&gt;", ""); Response.Write(sb.ToString()); } </script> <html> <body> <form id="form1" runat="server"> <asp:TextBox ID="htmlInputTxt" Runat="server" TextMode="MultiLine" Width="318px" Height="168px" /> <asp:Button ID="submitBtn" Runat="server" Text="Submit" OnClick="submitBtn_Click" /> </form> </body> </html>
  • Use type-safe SQL parameters for data access

    Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code. An additional benefit of using a parameters collection is that you can enforce type and length checks. Values outside of the range trigger an exception. You can use these parameters with stored procedures or dynamically constructed SQL command strings.

    Using stored procedures does not necessarily prevent SQL injection. The important thing to do is use parameters with stored procedures. If you do not use parameters, your stored procedures can be susceptible to SQL injection if they use unfiltered input.

    The following code shows how to use SqlParameterCollection when calling a stored procedure.

    using System.Data; using System.Data.SqlClient; using (SqlConnection connection = new SqlConnection(connectionString)) { DataSet userDataset = new DataSet(); SqlDataAdapter myCommand = new SqlDataAdapter("uspGetOrderList", connection); myCommand.SelectCommand.CommandType = CommandType.StoredProcedure; myCommand.SelectCommand.Parameters.Add("@OrderNumber", SqlDbType.VarChar, 11); myCommand.SelectCommand.Parameters["@OrderNumber"].Value = OrderNumberTextBox.Text; myCommand.Fill(userDataset); }

    The @OrderNumber parameter is treated as a literal value and not as executable code. Also, the parameter is checked for type and length. In the preceding code example, the input value cannot be longer than 11 characters. If the data does not conform to the type or length defined by the parameter, the SqlParameter class throws an exception.

    You should review your application’s use of stored procedures because simply using stored procedures with parameters does not necessarily prevent SQL injection. For example, the following parameterized stored procedure has several security vulnerabilities.

    CREATE PROCEDURE dbo.uspRunQuery @var ntext AS exec sp_executesql @var GO

    The stored procedure executes whatever statement is passed to it. Consider the @var variable being set to:

    DROP TABLE ORDERS;

    If you cannot use stored procedures, you should still use parameters when constructing dynamic SQL statements. The following code shows how to use SqlParametersCollection with dynamic SQL.

    using System.Data; using System.Data.SqlClient; using (SqlConnection connection = new SqlConnection(connectionString)) { DataSet userDataset = new DataSet(); SqlDataAdapter myDataAdapter = new SqlDataAdapter("SELECT OrderId, OrderNumber FROM Orders WHERE OrderNumber = @OrderNumber", connection); myCommand.SelectCommand.Parameters.Add("@OrderNumber", SqlDbType.VarChar, 11); myCommand.SelectCommand.Parameters["@OrderNumber"].Value = OrderNumberTextBox.Text; myDataAdapter.Fill(userDataset); }

    If you concatenate several SQL statements to send a batch of statements to the server in a single round trip, you can still use parameters if you make sure that parameter names are not repeated i.e. use unique parameter names during SQL text concatenation.

    SELECT OrderId, OrderNumber FROM Orders WHERE OrderNumber = 'PO123' using System.Data; using System.Data.SqlClient; using (SqlConnection oConn = new SqlConnection(connectionString)) { SqlDataAdapter oAdapter = new SqlDataAdapter( "SELECT CustomerID INTO #Temp1 FROM Customers " + "WHERE CustomerID > @custIDParm; " + "SELECT CompanyName FROM Customers " + "WHERE Country = @countryParm and CustomerID IN " + "(SELECT CustomerID FROM #Temp1);", oConn); SqlParameter custIDParm = oAdapter.SelectCommand.Parameters.Add("@custIDParm", SqlDbType.NChar, 5); custIDParm.Value = customerID.Text; SqlParameter countryParm = oAdapter.SelectCommand.Parameters.Add("@countryParm", SqlDbType.NVarChar, 15); countryParm.Value = country.Text; oConn.Open(); DataSet dataSet = new DataSet(); oAdapter.Fill(dataSet); }
  • Use a least privileged account that has restricted permissions in the database

    Ideally, you should only grant execute permissions to selected stored procedures in the database and provide no direct table access. The problem is more severe if your application uses an over-privileged account to connect to the database. For example, if your application’s login has privileges to eliminate a database, then without adequate safeguards, an attacker might be able to perform this operation.

    If you use Windows authentication to connect, the Windows account should be least-privileged from an operating system perspective and should have limited privileges and limited ability to access Windows resources. Additionally, whether or not you use Windows authentication or SQL authentication, the corresponding SQL Server login should be restricted by permissions in the database.

    Consider the example of an ASP.NET application running on Microsoft Windows Server 2003 that accesses a database on a different server in the same domain. By default, the ASP.NET application runs in an application pool that runs under the Network Service account. This account is a least privileged account.

    1. Create a SQL Server login for the Web server’s Network Service account. The Network Service account has network credentials that are presented at the database server as the identity DOMAIN\WEBSERVERNAME$. For example, if your domain is called XYZ and the Web server is called 123, you create a database login for XYZ\123$.
    2. Grant the new login access to the required database by creating a database user and adding the user to a database role.
    3. Establish permissions to let this database role call the required stored procedures or access the required tables in the database. Only grant access to stored procedures the application needs to use, and only grant sufficient access to tables based on the application’s minimum requirements. If the ASP.NET application only performs database lookups and does not update any data, you only need to grant read access to the tables. This limits the damage that an attacker can cause if the attacker succeeds in a SQL injection attack.
  • Use Character Escaping Techniques

    In situations where parameterized SQL cannot be used, consider using character escaping techniques. If you are forced to use dynamic SQL and parameterized SQL cannot be used, you need to safeguard against input characters that have special meaning to SQL Server (such as the single quote character). If not handled, special characters such as the single quote character in the input can be utilized to cause SQL injection.

    Escape routines add an escape character to characters that have special meaning to SQL Server, thereby making them harmless.

    private static string GetStringForSQL(string inputSQL) { return inputSQL.Replace("'", "''"); }

    Special input characters pose a threat only with dynamic SQL and not when using parameterized SQL. Your first line of defense should always be to use parameterized SQL.

  • Avoid disclosing database error information

    In the event of database errors, make sure you do not disclose detailed error messages to the user. Use structured exception handling to catch errors and prevent them from propagating back to the client. Log detailed error information locally, but return limited error details to the client.

    If errors occur while the user is connecting to the database, be sure that you provide only limited information about the nature of the error to the user. If you disclose information related to data access and database errors, you could provide a malicious user with useful information that he or she can use to compromise your database security. Attackers use the information in detailed error messages to help deconstruct a SQL query that they are trying to inject with malicious code. A detailed error message may reveal valuable information such as the connection string, SQL server name, or table and database naming conventions. See my other post on Exception Handling – Do’s and Dont’s.

    You can use the <customErrors> element to configure custom, generic error messages that should be returned to the client in the event of an application exception condition.

    Make sure that the mode attribute is set to "remoteOnly" in the web.config file as shown in the following example.

    <customErrors mode="remoteOnly" />

    After installing an ASP.NET application, you can configure the setting to point to your custom error page as shown in the following example.

    <customErrors mode="On" defaultRedirect="YourErrorPage.htm" />

    Conclusion

    The above list is just some points found on MSDN on how you can make your site more secure by effectively preventing SQL injection attacks. You should always be reviewing your code to find these or other security vulnerabilities; remember all type of attacks start with some input, and your first line of defense should be input validation using both client-side and server-side validation.

    Technorati Tags: ,

  • Creating AJAX Validator Control

    May 25, 2008 5 comments

    Imagine that you are creating a website registration form and you need to validate a Login ID or Email field. You want to make sure that the Login ID or Email entered does not already exist in the database. You could use the CustomValidator control to call a server-side function to check whether the field is unique in the database.

    <asp:TextBox id="txtEmail" Runat="server" /> <asp:CustomValidator id="valEmail" ControlToValidate="txtEmail" Text="Email already exists" OnServerValidate="valEmail_ServerValidate" Runat="server" />
    void valEmail_ServerValidate(Object source, ServerValidateEventArgs args) { if (EmailAlreadyExists(args.Value)) args.IsValid = false; else args.IsValid = true; }

    This of course causes a postback to the server where the server-side function is executed and the page is refreshed. This can be frustrating to the user to have to enter all the fields and submit and the page refreshes only to find out that the Email address is already in the system.

    To provide a better user experience we somehow need to call the server-side function from the client without causing a postback. Using AJAX (Asynchronous JavaScript and XML) we can create a validator control to call the server-side validation function from the client. The advantage of using AJAX is that no postback to the server is apparent to the user.

    Our control needs to inherit from the BaseValidator class and also implement the ICallbackEventHandler interface. The BaseValidator class serves as the abstract base class for validation controls and provides the core implementation for all validation controls. The BaseValidator requires you to implement a single method:

    • EvaluateIsValid – returns true when the form field being validated is valid.

    The BaseValidator class also includes several other methods that you can override or otherwise use. The most useful of these methods is the following:

    • GetControlValidationValue – enables you to retrieve the value of the control being validated.

    When you create a custom validation control, you override the EvaluateIsValid() method and, within the EvaluateIsValid() method, you call GetControlValidationValue to get the value of the form field being validated.

    public class MyAjaxValidator : BaseValidator, ICallbackEventHandler { public event ServerValidateEventHandler ServerValidate; string _controlToValidateValue; protected override bool EvaluateIsValid() { string controlToValidateValue = this.GetControlValidationValue(this.ControlToValidate); return ExecuteValidationFunction(controlToValidateValue); } private bool ExecuteValidationFunction(String controlToValidateValue) { ServerValidateEventArgs args = new ServerValidateEventArgs(controlToValidateValue, this.IsValid); if (ServerValidate != null) ServerValidate(this, args); return args.IsValid; }

    The ICallbackEventHandler interface defines two methods that are called on the server when an AJAX request is made from the client:

    • RaiseCallbackEvent – called to handle the event, passing the event argument as a parameter
    • GetCallbackResult – returns the result of the callback
    public void RaiseCallbackEvent(string eventArgument) { _controlToValidateValue = eventArgument; } public string GetCallbackResult() { return ExecuteValidationFunction(_controlToValidateValue).ToString(); }

    In the OnPreRender() method, a JavaScript include file and startup script are registered.

    protected override void OnPreRender(EventArgs e) { String eventRef = Page.ClientScript.GetCallbackEventReference(this, "", "", ""); String includeScript = Page.ResolveClientUrl("~/Scripts/MyAjaxValidator.js"); Page.ClientScript.RegisterClientScriptInclude("MyAjaxValidator", includeScript); String startupScript = String.Format(“document.getElementById('{0}').evaluationfunction = 'MyAjaxValidatorEvaluateIsValid';", this.ClientID); Page.ClientScript.RegisterStartupScript(this.GetType(), "MyAjaxValidator", startupScript, true); base.OnPreRender(e); } protected override bool DetermineRenderUplevel() { return Context.Request.Browser.SupportsCallback; }

    The JavaScript include file contains the client-side functions that are called when the MyAjaxValidator validates a form field on the client. The startup script associates the client-side MyAjaxValidatorEvaluateIsValid() function with the MyAjaxValidator control. The client-side validation framework automatically calls this JavaScript function when performing validation.

    function MyAjaxValidatorEvaluateIsValid(val) { var value = ValidatorGetValue(val.controltovalidate); WebForm_DoCallback(val.id, value, MyAjaxValidatorResult, val, MyAjaxValidatorError, true); return true; } function MyAjaxValidatorResult(returnValue, context) { if (returnValue == 'True') context.isvalid = true; else context.isvalid = false; ValidatorUpdateDisplay(context); } function MyAjaxValidatorError(message) { alert('Error: ' + message); }

    The MyAjaxValidatorEvaluateIsValid() JavaScript method initiates an AJAX call by calling the WebForm_DoCallback() method. This method calls the server-side validation function associated with the MyAjaxValidator control. When the AJAX call completes, the MyAjaxValidatorResult() method is called. This method updates the display of the validation control on the client.

    The following page illustrates how you can use the MyAjaxValidator control. This page handles the MyAjaxValidator control’s ServerValidate event to associate a custom validation function with the control. The validation function checks whether a email already exists in the database. If you enter a email that already exists, a validation error message is displayed. The message is displayed in the browser before you submit the form back to the server.

    <form id="form1" runat="server"> <asp:Label id="lbEmail" Text="Email:" AssociatedControlID="txtEmail" Runat="server" /> <asp:TextBox id="txtEmail" Runat="server" /> <custom:MyAjaxValidator id="valEmail" ControlToValidate="txtEmial" Text="Email already exists" OnServerValidate="valEmail_ServerValidate" Runat="server" /> <br /> <!--some other controls here --> <br /> <asp:Button id="btnSubmit" Text="Submit" Runat="server" OnClick="btnSubmit_Click" /> </form>

    And in code behind

    protected void valEmail_ServerValidate(object source, ServerValidateEventArgs args) { if (EmailAlreadyExists(args.Value)) args.IsValid = false; else args.IsValid = true; }

    It is important to realize that you can associate any server-side validation function with the MyAjaxValidator. You can perform a database lookup, call a web service, or perform a complex mathematical function. Whatever function you define on the server is automatically called on the client.

    Complete code for MyAjaxValidator:

    public class MyAjaxValidator : BaseValidator, ICallbackEventHandler { public event ServerValidateEventHandler ServerValidate; string _controlToValidateValue; protected override bool EvaluateIsValid() { string controlToValidateValue = this.GetControlValidationValue(this.ControlToValidate); return ExecuteValidationFunction(controlToValidateValue); } protected override void OnPreRender(EventArgs e) { String eventRef = Page.ClientScript.GetCallbackEventReference(this, "", "", ""); String includeScript = Page.ResolveClientUrl("~/Scripts/MyAjaxValidator.js"); Page.ClientScript.RegisterClientScriptInclude("MyAjaxValidator", includeScript); String startupScript = String.Format(“document.getElementById('{0}').evaluationfunction = 'MyAjaxValidatorEvaluateIsValid';", this.ClientID); Page.ClientScript.RegisterStartupScript(this.GetType(), "MyAjaxValidator", startupScript, true); base.OnPreRender(e); } protected override bool DetermineRenderUplevel() { return Context.Request.Browser.SupportsCallback; } public void RaiseCallbackEvent(string eventArgument) { _controlToValidateValue = eventArgument; } public string GetCallbackResult() { return ExecuteValidationFunction(_controlToValidateValue).ToString(); } private bool ExecuteValidationFunction(String controlToValidateValue) { ServerValidateEventArgs args = new ServerValidateEventArgs(controlToValidateValue, this.IsValid); if (ServerValidate != null) ServerValidate(this, args); return args.IsValid; } }
     
    REF:
    Sams ASP.Net 2.0 by Stephen Walther
     

    Tags: , ,

    Using Validation Application Block in ASP.NET

    May 19, 2008 3 comments

    Any web page which requires input from the user simply cant allow just any data to be entered because the data might be too long, missing or incorrect. We need to validate the data entered by the users in a number of ways; for example, First Name and Last Name might be required fields and Date of Birth cannot be greater than the current date etc. We can very well use the client side validators provided by ASP.NET like RequiredFieldValidator, CompareValidator or RegularExpressionValidtor but is that really enough? What if JavaScript is disabled by the client? What if we need to validate our business objects? It is often important to validate data several times within the same application. For example, you may need to validate object instances that you:

    • Generate in separate tiers or components of your application
    • Retrieve from a cache, a repository, or a third-party data access layer
    • Receive from a Web Service as an object instance or a set of property values
    • Reconstruct from existing values, perhaps populating them by copying properties from a similar object or using values retrieved from a database

    Enter the Enterprise Library with its Validation Application Block.

    The Validation Application Block is designed to address the most common tasks developers face when they must validate input either from a user or another system. The Validation Application Block provides a comprehensive series of validation components that you can apply through configuration, or through attributes applied directly to classes, class members, plus UI controls for use in both ASP.NET and Windows Forms applications.

    One of the major advantages with Validation Application Block is that you can define rule sets within your application configuration file, with each rule set defining the types of validation to undertake and the individual parameters for that validation process. This means that administrators can quickly and easily change the validation rules and parameters without requiring any changes to the existing code – avoiding the risk of code errors, recompilation issues, and application downtime.

    The Validation Application Block is designed to do the following:

    • Encapsulate the logic used to perform the most common validation tasks into minimal application code.
    • Relieve developers of the requirement to write duplicate code and custom code for common validation tasks.
    • Allow validation rules to be changed after the application has been deployed, and ensure that changes happen simultaneously and consistently.

    There are four ways that you can associate validators with your types:

    • You can use configuration.
    • You can use attributes.
    • You can use a combination of configuration and attributes.
    • You can use self validation, which means that you include validation logic within the object you want to validate.

    The Validation Application Block contains a wide range of validators that you can use to check almost any type of property or value. The built-in validators include:

    • Range Validators –
      • Range Validator – checks that a value falls within a specified range. The range may be either closed, which means it has both a lower and an upper bound specified, or open, which means that it only has one bound specified. The Range Validator can be used with any type that implements the IComparable interface. This includes all numeric types and strings. While it is possible, in code, to use this validator with DateTime types, the Date Time Range Validator may be a better choice because it allows you to take advantage of attributes and configuration.
      • Date Time Range Validator – checks that a DateTime object falls within the specified range.
      • String Length Validator – checks that the length of the string is within the specified range. The range may include or exclude the endpoints by omitting the lower or upper bound.
    • String Validators
      • Contains Characters Validator – checks that an arbitrary string, such as a string entered by a user in a Web form, contains any or all of the characters that are specified by the CharacterSet property.
      • Regular Expression Validator – checks that the value matches the pattern specified by a regular expression.
      • Type Conversion Validator – checks that a string can be converted to a specific type. For example, the validator can check that "6.32" can be converted to a Double type or that "2007-02-09" can be converted to a DateTime type.
    • Set Validators
      • Domain Validator – checks that a value is one of the specified values in a specified set. For example, it can check that a name is "Tom," "Dick," "Harry," or "George" or that an integer is 2, 3, 5, 7, or 11. If the set only contains one value, you can use this validator to check for equality.
      • Enum Conversion Validator – checks that a string can be converted to a value in a specified enum type. For example, it can check that "Blue" can be converted to a value in the Color enumeration.
    • Comparison Validators
      • Property Comparison Validator – compares the value to be checked with the value of a property. For example, a n AuctionItem object, the current bid is greater than or equal to the minimum bid.
      • Relative Date Time Validator – checks that the DateTime value falls within a specified range using relative times and dates.
    • Object Validators
      • Not Null Validator – checks that the value is not null.
      • Object Validator – causes validation to occur on an object reference. All validators defined for the object’s type will be invoked, just as if the Validation.Validate method had been called on the object. If the object you want to validate is null, the validation is ignored. If the reference is to an instance of a type that is not compatible with the configured target’s type, the validation fails. This validator is helpful for validating tree-structured data.
      • Object Collection Validator – checks that the object is a collection of the specified type and then invokes validation on each element of the collection. If the object you want to validate is null, the validation is ignored. If the object you want to validate is not a collection, then the validation fails and the rule set is not applied. If there are elements in the collection that are of a different type than the one you specified for the object, then the validation for these elements fails but this does not affect validation for the other elements.

    The Validation Application Block also provides the following composite validators which allow you to combine other validators by nesting them within this type of validator to create complex validation rules.

    • And Composite Validator – requires that all the validators that make up the composite validator be true. For example, you can use the And Composite Validator to require that the Not Null Validator AND the Date Time Range Validator be True. Because the Validation Application Block’s default behavior is to AND validators, you only need this validator to implement complex logic.
    • Or Composite Validator – requires that at least one of the validators that make up the composite validator be True. For example, you can use the Or Composite Validator to require that the Not Null Validator OR the Date Time Range Validator be True.

    Each validator also has a Negated property, which reverses the operation of the validator so that it returns False if the value is valid, and True if not. This is useful when you combine validators using the And Composite Validator and the Or Composite Validator.

    Assume that our customer entity is as follows and we want to validate the fields within this object for some business rules. For example, Postal Code format nnnnn[-nnnn] etc.

    public class Customer { public string Name { get; set; } public string Address { get; set; } public string City { get; set; } public string PostalCode { get; set; } public int EmployeeCount { get; set; } public DateTime LastReportDate{ get; set; } }

    The first step when using the Validation Application Block is to create rule set(s) for our type / object. To create a rule set for an object, you must first create and compile that assembly. Once you have a target object class, open the configuration file for your application in the Configuration Editor integrated within Visual Studio by right-clicking on the Web.config file in the Solution Explorer window and select Edit Enterprise Library Configuration.

    In the configuration editor, right click on the application node and select New, then click Validation Application Block to add the Validation Application Block to your application. Then right-click on the new Validation Application Block node, select New, and click Type. In the Type Selector dialog, click the Load an assembly button and navigate to the folder containing your target object. Click Open to load this assembly. Find your target assembly in the list and select the target class to which you want to attach a rule set.

    Click OK, and the class appears in the configuration under the Validation Application Block node. Now you are ready to create the rule set.

    Right-click on the new target object node in the configuration editor, select New, and click Rule Set. Change the name of the rule set as required – you will use the name in your code so you should specify a name that will help you to read and debug your code, especially if you define more than one rule set.

    The next stage is to select the members of the target object that you want to validate. Right-click on the new rule set node, select New, and click Choose Members to display a dialog containing all the public members of the target object. Select the required members and click OK to close the dialog and add these members to the rule set.

    You now have a hierarchy that contains the list of members to which you will add validators. For each target object member, right-click on it, select New, and click the type of validator you want to add. As you add each one, use the Properties window in Visual Studio to set the properties you require for each validator.

    For example, the CompanyAddress property has a String Length Validator attached with the following properties set:

    <validation> <type assemblyName="TestApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" name="TestApp.Customer"> <ruleset name="ExampleRuleSet"> <properties> <property name="Name" > <validator lowerBound="5" lowerBoundType="Inclusive" upperBound="100" upperBoundType="Inclusive" negated="false" messageTemplate="Customer address must be between 5 and 100 characters" messageTemplateResourceName="" messageTemplateResourceType="" tag="CustomerAddressValidator" type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.StringLengthValidator, Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="String Length Validator"/> </property> <property name="Address"> <validator lowerBound="5" lowerBoundType="Inclusive" upperBound="100" upperBoundType="Inclusive" negated="false" messageTemplate="Customer address must be between 5 and 100 characters" messageTemplateResourceName="" messageTemplateResourceType="" tag="CustomerAddressValidator" type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.StringLengthValidator, Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="String Length Validator"/> </property> <property name="City"> <validator lowerBound="2" lowerBoundType="Inclusive" upperBound="30" upperBoundType="Inclusive" negated="false" messageTemplate="City name must be between 2 and 30 characters" messageTemplateResourceName="" messageTemplateResourceType="" tag="CustomerCityValidator" type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.StringLengthValidator, Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="String Length Validator"/> </property> <property name="PostalCode"> <validator pattern="\d{5}(-\d{4})?" options="None" patternResourceName="" patternResourceType="" messageTemplate="Postal code must be in the form nnnnn[-nnnn]" messageTemplateResourceName="" messageTemplateResourceType="" tag="CustomerPostalCodeValidator" type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.RegexValidator, Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="Regex Validator"/> </property> <property name="EmployeeCount"> <validator lowerBound="1" lowerBoundType="Inclusive" upperBound="100" upperBoundType="Inclusive" negated="false" messageTemplate="Employee count must be between 1 and 100" messageTemplateResourceName="" messageTemplateResourceType="" tag="EmployeeCountValidator" type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.RangeValidator, Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="Range Validator"/> </property> <property name="LastReportDate"> <validator lowerBound="2007-01-01" lowerBoundType="Inclusive" upperBound="2008-03-28" upperBoundType="Inclusive" negated="false" messageTemplate="Report Date must be between 1st Jan and 31st Dec 2007" messageTemplateResourceName="" messageTemplateResourceType="" tag="LastReportDateValidator" type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.DateTimeRangeValidator, Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="Date Range Validator"/> </property> </properties> </ruleset> </type> </validation>

    ASP.NET integration uses a class named PropertyProxyValidator, which implements a control that you can use within an ASP.NET Web page to perform UI validation. This control inherits from the ASP.NET validation control base class named BaseValidator, and is therefore effectively an ASP.NET validation control.

    The BaseValidator class exposes properties such as ControlToValidate, Display (None, Static, Dynamic), EnableClientScript, Enabled, IsValid, SetFocusOnError, and ValidationGroup. The PropertyProxyValidator class also exposes the Validate method, which you can use to initiate validation of specific validators if required. However, all the instances of the PropertyProxyValidator class you place in a page integrate with the ASP.NET validation system, and so you can cause validation by calling the Validate method of the Page class, and check the result using the IsValid property of the Page class – this does not occur automatically.

    By integrating the Validation Application Block with your applications, you can reuse your validation rules across several levels of your system architecture. Integration allows you reuse the validators that are associated with your application classes when you perform validation at the user-interface level for ASP.NET . The integration provided by the Validation Application Block at the user-interface level does the following:

    • It provides a way to associate properties of validated application objects with user-interface controls.
    • It provides a way to convert values from an input data type to an application-specific data type. For example, you can convert a string input to a System.DateTime value.
    • It helps avoid coding errors in type names and property names. For example, it throws exceptions when type names or property names cannot be found.
    • It does not require instances of application objects to be created in order for validators to be invoked at the user-interface level. In other words, you do not need to instantiate a Customer object just to check whether an input string entered by the user meets the validation requirements of the Customer.Name property.

    To use the PropertyProxyValidator class, you simply add instances to the ASP.NET page, either by declaring them within the .aspx file or by generating instances dynamically at runtime and adding them to the Controls collection of the Page object or another container control. The process is identical to adding ASP.NET built-in validation controls such as the RequiredFieldValidator or any other ASP.NET control) to a page.

    The only real differences when working with the Validation Application Block compared to the ASP.NET validation controls are:

    • You must include an @Register directive in the ASP.NET page to register the integration assembly that contains the PropertyProxyValidator control:
      <%@ Register Assembly="Microsoft.Practices.EnterpriseLibrary.Validation.Integration.AspNet" Namespace="Microsoft.Practices.EnterpriseLibrary.Validation.Integration.AspNet" TagPrefix="EntLibValidators" %>
    • You use only one type of validation control, the PropertyProxyValidator control, for all validation operations. The actual operation and parameters appear in the configuration file or in attributes applied to the target object class and its members. You should have a target object class defined that supports validation through configuration or attributes.
    • You specify the name of the rule set, the type name of the target object, and the target object member (method or property name) in the PropertyProxyValidator control declaration. For example:
    <EntLibValidators:PropertyProxyValidator ID="CustomerNameValidator" runat="server" ControlToValidate="txtName" PropertyName="Name" RulesetName="ExampleRuleSet" SourceTypeName="TestApp.Customer" EnableViewState="false"/>

    For each validated UI input control, specify that input control’s ID property as the ControlToValidate property of the PropertyProxyValidator control. Also set the RulesetName, SourceTypeName, and PropertyName properties to the appropriate values based on your application configuration.

    Our test application displays textboxes for the six properties of the target object. If you click the Submit button, after entering values in the text boxes, the code creates an instance of the target class with valid values, performs validation on the object, and displays the property values and the validation result in the page.

    If you now edit the values in the text boxes so that they are outside the range of valid values, and click the Submit button again, the page displays a list of errors it encounters when validating the new object instance.

    For each invalid property value, the page displays the contents of the MessageTemplate for the validator, the name of the target property, the value of the Tag property of the validator, and the type name of the target object.

    To validate the UI control values, add code to the handler for the button or other control that submits the page. A separate routine named CreateLocalCompanyObject performs the task of applying the validated UI values to a new instance of the target object, and displaying its properties in the page:

    // force validators to check control values Page.Validate(); if (Page.IsValid) { // create sample object instance and set properties CreateLocalCustomerObject(); } else { lblResult.Text = "Validation errors encountered by ASP.NET Integration Validators<p />"; }
    private void CreateLocalCustomerObject() { // create sample object instance and set properties TestApp.Customer objCustomer = new TestApp.Customer(); objCustomer.Name = txtName.Text; objCustomer.Address = txtAddress.Text; objCustomer.City = txtCity.Text; objCustomer.PostalCode = txtPostalCode.Text; objCustomer.EmployeeCount = Int32.Parse(txtEmployees.Text); objCustomer.LastReportDate = DateTime.Parse(txtReportDate.Text); // display and validate property values DisplayAndValidateSampleObject(objCustomer); }

    Unlike the ASP.NET UI validation controls, which react to an event in the ASP.NET page cycle to perform validation, the Validation Application Block validators must be explicitly executed by calling the static Validate method of the block. The easiest way to do this is to use the Validation façade. The façade allows you to you to create a Validator instance and validate an object with a single line of code. This is shown in the following code example.

    Customer cust = new Customer(); ValidationResults results = Validation.Validate<Customer>(cust, "rulesetname");

    If you do not want to use the façade, you can use the following code, which is the equivalent.

    Customer cust = new Customer(); Validator<Customer> validator = ValidationFactory.CreateValidator<Customer>("rulesetname"); ValidationResults results = validator.Validate(cust);

    Use the CreateValidator method on the ValidationFactory class to first get a reference to the Validator instance, and then use the Validate method to validate the object.

    The Validate method of the Validation façade accepts as parameters the name of the object to validate, and optionally the names of the validation rule sets to apply. For example, if you have only a single rule set named RuleSetA defined in the configuration of the application, you can apply this rule set to an object named customer using the following code.

    ValidationResults results = Validation.Validate(cust, "RuleSetA");

    If you have two rule sets named RuleSetA and RuleSetB defined in the configuration of the application, you can apply the rules from both using the following code.

    ValidationResults results = Validation.Validate(cust, "RuleSetA", "RuleSetB");

    The Validate method returns an instance of the ValidationResults class, which is a collection containing a ValidationResult instance for each validation failure. The ValidationResult class exposes properties that allow you to obtain the value of the Key (the member name if available), the Message describing the validation error, the value of the validator Tag property, the type name of the Target object, and the name of the Validator. There is also the NestedValidationResults property, which exposes a ValidationResults collection containing the validation errors for any nested validators, when using a composite validator.

    Our DisplayAndValidateSampleObject() function calls the Validate method, and then checks if there were any validation errors by examining the IsValid property of the returned ValidationResults collection. If there are errors, the code iterates through the collection adding the values of the Key, Tag, and Target properties of each ValidationResults instance to the StringBuilder. If there are no errors, it adds a suitable message to the StringBuilder instead. Finally, the code displays the contents of the StringBuilder in a Label control on the page:

    ... // validate the property values using the configured rule set ValidationResults results; results = Validation.Validate(targetObject, "ExampleRuleSet"); // get validation results if (!results.IsValid) { builder.Append("<b>Validation Errors:</b>:<br />"); foreach (ValidationResult result in results) { builder.Append(String.Format("- <b>{0}</b><br />", result.Message)); builder.Append(String.Format("&nbsp; (Key: {0}, ", result.Key.ToString())); builder.Append(String.Format("Tag: {0}, ", result.Tag)); builder.Append(String.Format("Target: {0})<br />", result.Target.ToString())); } } else { builder.Append("All object property values are valid."); } // display results in Label control lblResult.Text = builder.ToString(); ...

    It is always a good idea to repeat on the server any UI validation you carry out before using posted values in your application. This protects against spoofing attacks; and against issues that may arise is client browsers do not fully support or correctly process client-side script. However, unlike the ASP.NET validation controls, the PropertyProxyValidator controls only perform validation server-side, and not through client-side script.

    Using the Enterprise Library Validation Application Block in ASP.NET applications allows concentrating on the use of rule sets that allow validation across the UI and object instances within the application tiers.

    While ASP.NET provides a fully-featured set of UI validation controls, these do not always fulfill the requirements of enterprise-level applications. The Validation Application Block supports a wider range of validators, has features to allow composition and negation of validators, and supports validation using configuration rules as well as attributes applied directly to classes and class members.

    One should combine the Validation Application Block validators with the ASP.NET built-in validators as required. The PropertyProxyValidator control that supports ASP.NET integration is itself a descendant of the ASP.NET validator base class, and so behaves and can be handled in the same way as the ASP.NET validation controls.

     

    Enterprise Library 4.0 – Just Released

    May 18, 2008 1 comment

    Congratulations to the Enterprise Library Team for their release of Enterprise Library 4.0. A few enhancements and bug fixes in this release, but most importantly it comes with Unity IoC Integration. As you may or may not know, Unity is Microsoft Patterns & Practices lightweight, extensible dependency injection container with support for constructor, property, and method call injection. The patterns & practices Enterprise Library is a collection of reusable application blocks designed to assist software developers with common enterprise development challenges. This following application blocks are included: Caching Application Block, Cryptography Application Block, Data Access Application Block, Exception Handling Application Block, Logging Application Block, Policy Injection Application Block, Security Application Block, Validation Application Block, and Unity Application Block.

    Download Enterprise Library 4.0 here.

    This release of Enterprise Library includes the following:

    • Integration with the Unity Application Block
    • Windows Management Instrumentation (WMI) 2.0 support and improved instrumentation
    • Performance improvements (particularly, in the Logging Application Block)
    • Pluggable Cache Managers
    • Visual Studio 2008 support
    • Bug fixes

    Note: existing public APIs (v3.1) are still supported.

    Check out CodePlex for Unity and PnPGuidance as well.

    The Application Block Software Factory and the Strong Naming Guidance Package are not included in this release but are available as a separate download. Thus, there is no longer a dependency on Guidance Automation Extensions (GAX).

    If you already know and love the Enterprise Library:

    • Check out the change log for this release;
    • Upgrade to V4.0—no code change is required—simply update the references to the corresponding application block assemblies and to the common assemblies;
    • Download the updated QuickStarts and run through the Unity-integrated examples to get the flavor of new dependency injection style of using the Enterprise Library

    Exception Handling – Do’s and Dont’s

    May 6, 2008 6 comments

    Exceptions provide a consistent mechanism for identifying and responding to error conditions. Effective exception handling will make code more robust and easier to debug. Exceptions are a tremendous debugging aid because they help answer:

    • What went wrong
    • Where did it go wrong
    • Why did it go wrong

    What is answered by the type of exception thrown, where is answered by the exception stack trace, and why is answered by the exception message. If your exception is not answering all three questions, chances are they aren’t being used effectively.

    Following are some suggestions on Do’s and Don’ts for exception handling:

    • Don’t throw an exception when a simple if statement can be used to check for errors. Remember an exception is something that is out of the norm. For example, a simple if statement to check whether a connection is closed is much better than throwing an exception for the same.

    Do

    if(conn.State != ConnectionState.Closed) conn.Close();

    Don’t 

    try { conn.Close(); } catch(InvalidOperationException ex) { //do something with the error or ignore it }
    • Do use try/finally blocks around code that can potentially generate an exception and centralize your catch statements in one location. In this way, the try statement generates the exception, the finally statement closes or deallocates resources, and the catch statement handles the exception from a central location. This also has the additional benefit of making your code more readable. Consider a simple example where you want to create a temporary file and delete it afterwards even if an error occurs
    string Foo1(string fileName) { string fileContents; using(StreamReader sr = new StreamReader(fileName)) { fileContents =sr.ReadToEnd(); } File.Delete(fileName); return fileContents; }

    This code deletes the file just before the return statement; but what if an exception occurs in the lines above? it leaves the temporary file on the disk. Some people might try to solve it coding as this:

    string Foo1(string fileName)
    {
        try
        {
            string fileContents;
            using (StreamReader sr = new StreamReader(fileName))
            {
                fileContents = sr.ReadToEnd();
            }
            File.Delete(fileName);
            return fileContents;
        }
        catch (Exception)
        {
            File.Delete(fileName);
            throw;
        }
    }

    The above code does the job but its a bit more complex and the File.Delete is duplicated in the try and catch blocks. Now, see how the try/finally solution is more cleaner and robust:

    string Foo1(string fileName) { try { using (StreamReader sr = new StreamReader(fileName)) { return sr.ReadToEnd(); } } finally { File.Delete(fileName); } }

    Notice that we haven’t used the fileContents local variable now because we can return the contents of the ReadToEnd() method and the cleanup code executes after the return point. This is one of the advantages of having code that can run after the function returns: you can clean resources that may be needed for the return statement.

     

    • Don’t use finally blocks if all you need to do is call Dispose() on your object. Instead use "using" for objects which support the IDisposable interface. "using" will guarantee that the Dispose() method is called even if an exception occurs within the code block.
    • Do postfix your exception class names with the word "Exception". For example:
    public class FileNotFoundException : IOException { }
    • When creating user-defined exceptions, you must ensure that the metadata for the exceptions is available to code executing remotely, including when exceptions occur across application domains. For example, suppose Application Domain A creates Application Domain B, which executes code that throws an exception. For Application Domain A to properly catch and handle the exception, it must be able to find the assembly containing the exception thrown by Application Domain B. If Application Domain B throws an exception that is contained in an assembly under its application base, but not under Application Domain A’s application base, Application Domain A will not be able to find the exception and the common language runtime will throw a FileNotFoundException. To avoid this situation, you can deploy the assembly containing the exception information in two ways:
      • Put the assembly into a common application base shared by both application domains
        – or –
      • If the domains do not share a common application base, sign the assembly containing the exception information with a strong name and deploy the assembly into the global assembly cache.

    In situations where you are using remoting, you must ensure that the metadata for any user-defined exceptions is available at the server (callee) and to the client (the proxy object or caller).

    • Do use at least the three common constructors when creating your own exception classes. Failure to do so means your exception class will not be able to follow some of these Do’s and Don’t’s.
    public class FileNotFoundException : IOException { public FileNotFoundException() { } public FileNotFoundException(string message) : base(message) { } public FileNotFoundException(string message, Exception inner) : base(message, inner) { } }
    • Do use the predefined exceptions types for common cases and define your own custom exception types only for programmatic scenarios. For example, to enable a programmer to take a different action in code based on the exception class.
    • Do remember that exceptions are classes which can have properties for extra information. Include extra information in an exception (in addition to the description string) when there is a programmatic scenario where the additional information is useful. Don’t try and cram all information in the Message property.
    • Design classes so that an exception is never thrown in normal use. For example, a FileStream class exposes another way of determining whether the end of the file has been reached. This avoids the exception that is thrown if you read past the end of the file. The following example shows how to read to the end of the file.
      class FileRead { public void Open(FileStream fileToRead) { if (fileToRead == null) { throw new System.ArgumentNullException(); } int b; fileToRead.Seek(0, SeekOrigin.Begin); for (int i = 0; i < fileToRead.Length; i++) { b = fileToRead.ReadByte(); Console.Write(b.ToString()); } } }
    • Do throw an InvalidOperationException if a property set or method call is not appropriate given the object’s current state. For example, if a OpenSocket() method was unable to allocate the resource and returned null a subsequent Listen() method should throw a InvalidOperationException.
    • Do throw exceptions instead of returning special error codes or HRESULT.
      • Exceptions makes the common case faster, because when you return special values from methods, each method return needs to be checked and this consumes at least one processor register more, leading to slower code.
      • Special values can, and will be ignored. I’ve seen dozens of newsgroup posts asking for if there was some way to check if the method succeeded or not and turns out the method did return an enum of possible return codes.
      • Even if the return code was checked by the programmer its not much use as it does not tell me what, where and why went wrong. Its just a simple code which I may be able to lookup in the documentation but then again it could be a generic error code which simply tells me that the method failed and not why it failed. For all I know it could have failed because of some IOException or some ArgumentException.
      • There may not be a suitable value to return that can be used as an indicator for an error condition. I’ve seen countless methods return -1 to indicate an error condition but its not always suitable. What value would you return from the following function to represent a division by zero?
    • Do return special error code (null) for extremely common situations instead of exception. Wait a minute, wasn’t the point above about not to return error codes? What gives? It turns out most methods which return some resource in the .NET framework follow this rule. For example, Open returns null if the file is not found, but throws an error if the file cannot be opened (file is locked by some other process). But why this alternate rule for null?
      • null would be out of the norm and hence less code will be executed for the common case.
      • null cannot be ignored. Trying to ignore it will most likely throw an NullReferenceException.
    • Do clean up intermediate results and resources when throwing an exception. Callers should be able to assume that there are no side effects when an exception is thrown from a method. For example, if an exception is thrown from Foo1() then it should properly dispose of the objects before leaving the method.
    public void Foo1() { using(SqlConnection oConn = new SqlConnection()) { try { SqlCommand oCmd = oConn.CreateCommand(); //call some proc oConn.Open(); } catch(SqlException ex) { //handle exception throw; } finally { oConn.Close(); } } }
    • Don’t throw Exception(). It is too broad class and catching it could mean swallowing other exceptions. Instead create your own custom exceptions and derive from Exception class.
    [Serializable] class MyCustomException : Exception { }
    • Do mark your custom exceptions with [Serializable]. Your method might very well be called from remoting components or web services and if your exception is not serializable you will end up with a completely different exception hiding your original exception, making any bug extremely hard to debug and fix.
    • Don’t swallow an exception by putting an empty catch block. Never do this. If you don’t need to do anything when an exception is thrown then just don’t catch it and let other code try and handle it. Many times I’ve seen novice programmers will try and put try…catch on all events in an aspx page and catch(Exception ex) without doing anything with that exception. This effectively hides all errors from the user but what if this event was a button click for submitting an online shopping cart? The try…catch will hide the fact that the request failed but will not show it to the user, this will ultimately result in a customer support call by a frustrated user.

    The first class MyClass is on an assembly, and the second class (MyCCValidator) is on another assembly. On the development machine the code ran right, but on the QA machines, the code always returned "Invalid number", even if the entered number was valid.

    public class MyClass { public static string ValidateNumber(string userInput) { try { bool val = MyCCValidator.Validate(userInput); return "Valid number"; } catch (Exception) { return "Invalid number"; } } } public class MyCCValidator { public static bool Validate(string userInput) { return true; } }

    The problem was on our setup, which didn’t include the second assembly (ValidatorsLibrary). Now, we had a FileNotFoundException when the Validate was called, and the code assumed that it was because the number was invalid.

    • Don’t catch Exception. Always use the most specific exception for the code you are writing. Remember good code is not code that doesn’t throw exceptions. Good code throws exceptions as needed and handles only the exceptions it knows how to handle. The more specific the exception, the better your code answers what went wrong. For example, your code may respond to a FileNotFoundException by asking the user for a different file name.
    File prefsFile = new File(prefsFilename); try { readPreferences(prefsFile); } catch (FileNotFoundException e) { // alert the user that the specified file does not exist } catch (EOFException e) { // alert the user that the end of the file was reached } catch (ObjectStreamException e) { // alert the user that the file is corrupted } catch (IOException e) { // alert the user that some other I/O error occurred }

    Assuming IOException is the base class for FileNotFoundException, EOFException and ObjectStreamException. Should an IOException other than those specified by the first three catch blocks be thrown, the last catch block will handle it by presenting the user with a somewhat more generic error message. This way, the program can provide specific information when possible, but still handle the general case should an unanticipated file-related exception slip by.

     

    • Don’t use throw ex. Out of every property in the Exception class, the stack trace is one of the most useful information that an exception carries. If you need to put some exception handling in the catch block and re-throw the exception so it can be logged / handled in the UI block with an appropriate message:

    Don’t

    try { //code that throws an exception } catch(Exception ex) { //handle exception throw ex; }

    Do

    try { //code that throws an exception } catch(Exception ex) { //handle exception throw;
    }

    When you examine the stack trace of the first code sample the point of the exception will be the line "throw ex;" hiding the real error location. "throw;" on the other hand will simply rethrow the exception and will keep your stack trace intact.

    • Don’t log Exception.Message. Always log Exception.ToString() instead of Exception.Message. If you only log Exception.Message, you’ll only have something like "Object reference not set to an instance of an object" in your exception log, all this tells me is that some where an exception occurred and some object was set to null. It answers the what but not the where and why. Exception.ToString() will give you a stack trace, the inner exception and the message.
    • Do use Debug.Assert to validate arguments to your methods during development only (debug build). Assert will throw an exception if the expression evaluates to false. This can be very useful in preventing null (or any invalid argument) being passed as an argument to your method. But don’t forget that Debug.Assert is removed from release code. For release builds you should throw ArgumentException or a class derived from ArgumentException if invalid parameters are passed.

    The above list is just some suggestions from my experiences. Consider them as a starting point for your own exception handling rules. Also, there are lots of good frameworks and libraries which deal with exception handling and logging. One such is the Microsoft Enterprise Library which contains Exception Handling and Logging Application Blocks. These libraries can be great tools in the hands of a programmer who follows strict design guidelines for exception handling and useless if you don’t follow such rules.

    In the end, the hardest part of debugging usually is not fixing the bug, but instead finding where in code the bug hides. By following the above list you can use exceptions to help you track down and eradicate bugs and make your programs more robust and user-friendly.

     

    Technorati Tags: ,