C#
  Home arrow C# arrow Page 8 - Exception Handling in C#
ASP Free Forums 
.NET  
ASP  
ASP Code  
ASP.NET  
ASP.NET Code  
BrainDump  
C#  
Code Examples  
Database  
Database Code  
IIS  
Microsoft Access  
MS SQL Server  
Visual Basic.NET  
Windows Scripting  
Windows Security  
XML  
ASP Web Hosting  
ASP.NET Web Hosting 
Dedicated Servers 
Moblin 
JMSL Numerical Library 
Windows Web Hosting
 
IBM® developerWorks 
Sun Developer Network 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
C#

Exception Handling in C#
By: Jon Jagger
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 22
    2004-01-28

    Table of Contents:
  • Exception Handling in C#
  • Separation of Concerns
  • The Solution, but More Issues
  • A Second Attempt
  • Fourth Time's
  • Using Statements
  • Do it Yourself?
  • struct Alternative

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    Exception Handling in C# - struct Alternative


    (Page 8 of 8 )

    AutoTextReader is a sealed class intended, as its name suggests, to be used as a local variable. It makes sense to implement it as a struct instead of class:


    public struct AutoTextReader IDisposable
    {
        
    // exactly as before
    }

    Using a struct instead of a class also gives you a couple of free optimizations. Since a struct is a value type it can never be null. This means the compiler must omit the null guard from generated finally block. Also, since you cannot derive from a struct its runtime type is always the same as its compile time type. This means the compiler can usually omit the cast to IDisposable from the generated finally block and thus avoid a boxing operation. (specifically, it can avoid the cast if Dispose is a public Implicit Interface Implementation rather than a non-public Explicit Interface Implementation). In other words, this:


    using (AutoTextReader scoped file.OpenText())
    {
        scoped
    .TextReader.Read(source0length);
    }

    is translated into this:


    {
        AutoTextReader scoped 
    = new file.OpenText();
        try
        
    {
            scoped
    .TextReader.Read(source0length);
        
    }
        finally
        
    {
            scoped
    .Dispose();
        
    }
    }

    It should come as no surprise that I prefer the using statement solution to the finally block solution. In fact, the using statement solution scores several extra points in comparison to the "ideal" solution. A using statement:

    1. Works! It always releases the resource.

    2. Is an extensible mechanism. It allows you to create an abstraction of resource release. Creating your own resource releaser types such as AutoTextReader is easy.

    3. Allows you to pair up the resource acquisition with the resource release. The best moment to organize the resource release is the moment you acquire the resource. If you borrow a book from a library you're told when to return it as you borrow it.

    4. Says explicitly, in syntax, that you are using a resource.

    5. Creates a scope for the variable holding the resource. Look carefully at the compiler translation of a using statement and you'll see that it cleverly includes a pair of outer braces:


    using (AutoTextReader scoped file.OpenText())
    {
    scoped
    .TextReader.Read(source0length);
    }
    scoped
    .TextReader.Close(); // scoped is not in scope here

    This is reminiscent of C++ declarations in conditions. Both allow you to restrict the scope of a variable so it's only usable when in scope and is only in scope when usable.


    DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

     

    C# ARTICLES

    - Working with Regular Expressions in C#
    - Sending Simple E-Mail in C#
    - Building C# Comparable Objects: IComparable ...
    - Color Transformation Applications in C# GDI+...
    - Performing Color Transformation Operations i...
    - Color Transformation in C# GDI+ Programming
    - Exceptions in C#
    - Overriding versus Overloading
    - Value Types and Reference Types
    - Defining Member and Type Visibility
    - Managing Files in C#
    - Working with Windows Registry in C#
    - Lossless Image Resizing in C#
    - Lossless Image Converting in C#
    - Creating an RSS Feed with ASP.Net Written in...





    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 5 hosted by Hostway