Click here to Skip to main content
Click here to Skip to main content

RAII (Resource Acquisition Is Initialization) C# Helper Classes

, 29 Oct 2010 CPOL
Rate this:
Please Sign up or sign in to vote.
Some useful RAII C# helper classes for functionality that does not implement IDisposable


What the Heck is RAII?

RAII stands for "Resource Acquisition Is Initialization". It is a programming idiom which ensures that there is no resource leak (like lost memory, open handles, dangling critical section monitors, etc.), even if an exception is thrown. For languages like C#, the lost memory is not of an issue, but the problem of "open handles" and "critical section monitors" is equally important.

Some languages provide a mechanism to deterministically and implicitly call one specific function at the end of the lifetime of an object instance (e.g. the destructor in C++). The RAII idiom in C++ takes benefit of that fact and places the "acquisition" of the resource into the constructor (= initialization), and releases the resource in the destructor.

E.g. the C++ auto pointer as well as any guard or sentry classes are implementing the RAII idiom. For more insight, see RAII Idiom.

In C++, a reporting sentry (RAII class) would log the text in its constructor and log again some text in its destructor (that is called when leaving the function body):

// this is C++ use of an RAII class
void f()
   ReportSentry reportSentry("function f");

C# does not know this deterministic and implicit destructor call, that's why I explain how I approach this issue in C#.

RAII in the C# World

Coming from a C++ background, I often did apply the RAII idiom. This was not only used for resources but for any kind of action that required symmetric "open-close", "add-remove", "set-reset", "open tag - close tag", "enter critical section - leave critical section", "report start-of-function - report end-of-function", etc. actions - no matter how the control flow left the current scope.

C# provides the well known IDisposable interface. Each class that implements this interface can be considered as "RAII-ready", i.e., one can use an instance of this class in a...

using (...) { ... }


But what to do if you have the need of RAII, but no class at hand for the using (...) { ... } statement?

This article shows some simple helper classes that provide an IDisposable wrapper class for an init and a cleanup delegate.

Of course, this is not at all rocket science - actually, it is very simple. It should help to clear up the mist of exception handling involved and focus on the normal control flow.

Using the Code

First, I show the two usages of RAII versus hand crafted side by side.

With RAII support classes Hand crafted
using (var objGuard = new RAIIGuard<int>(
                  () =>objStack.Pop(),
    if (objGuard.Item != 0)
    if (...)
         throw new ...;
int iTaken;
bool bTaken = false;
    // access the taken object
    iTaken = objStack.Pop();
    bTaken = true; 
    if (iTaken == 0)
    if (...)
         throw new ...;
    if (bTaken)

I consider the RAII supported approach more legible. If the lambda expressions hurt your eyes, you can always use delegates or methods, e.g.

private int Pop() { return Stack.Pop(); }
private void Push(int i) { Stack.Push(i); }
using (var objGuard = new RAIIGuard<int>(Pop, Push)) 

Conveniently, there are two classes to provide that function:

  1. one that has an init action and a cleanup action (e.g. login, logout)
  2. one that has an init function returning an object and a cleanup function taking that object (e.g. login and logout with a session object)
// used for symmetric actions like login, logout
public sealed class RAIIGuard: IDisposable
    private Action Cleanup { get; set; }
    public RAIIGuard(Action init, Action cleanup)
        Cleanup = cleanup;
        if (init != null) init();
    void IDisposable.Dispose() { if (Cleanup != null) Cleanup(); }
// used for symmetric actions that must pass
// over an object from init to cleanup and that
// need to provide the item to the "using" body
public sealed class RAIIGuard<T>: IDisposable
    private Action<T> Cleanup { get; set; }
    public T Item { get; private set; }
    public RAIIGuard(Func<T> init, Action<T> cleanup)
        Cleanup = cleanup;
        Item = (init != null) ? init() : default(T);
    void IDisposable.Dispose() { if (Cleanup != null) Cleanup(Item); }


It would still be nice if the committee "guarding" Wink | ;-) the C# language could re-consider to implement a native RAII support (e.g. where one can declare a guard as an instance of some kind of "value" type and at the end of the scope, a "Dispose" method is implicitly and deterministically called).

The approach above still requires a certain amount of cooperation by the client where as the pure RAII solution would not need cooperation by the client, i.e., in C#, one can still screw up the RAII idiom by not calling the Dispose() method Frown | :-( .

In the meantime, the approach shown above is good enough for me...


  • 2010-10-27 Initial version
  • 2010-10-27 Fixed some typos
  • 2010-10-29 Added more background on RAII, explicit implementation of Dispose() (Thanks to Roberto Collina)


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Andreas Gieriet
Founder eXternSoft GmbH
Switzerland Switzerland
I feel comfortable on a variety of systems (UNIX, Windows, cross-compiled embedded systems, etc.) in a variety of languages, environments, and tools.
I have a particular affinity to computer language analysis, testing, as well as quality management.
More information about what I do for a living can be found at my LinkedIn Profile and on my company's web page (German only).
Follow on   LinkedIn

Comments and Discussions

QuestionA slight modification PinmemberTobiasP14-Feb-12 8:19 
AnswerRe: A slight modification PinmemberAndreas Gieriet14-Feb-12 13:27 
GeneralRe: A slight modification PinmemberTobiasP15-Feb-12 0:56 
I fully agree that it should be used only in using statements. The modifications I did should not in any way be interpreted to suggest other uses. However, the only reason this class can be used in using statements is because it implements IDisposable and that means it strictly speaking should be expected to "release allocated resources", again quoting MSDN. The RAII usage here assigns a different meaning to its use of the IDisposable interface, so the child class no longer fulfills the promises of the base class (interface). But it can still be very practical if you are aware of the different usage.
The RAII pattern here in C# is more convoluted than the RAII pattern in C++ precisely because you have to remember to use using. You cannot force instances of the class to be used only in using statements. Therefore it is much easier to misuse the pattern in C# than it is in C++, and my modifications were made to make it harder to misuse without being detected. In your original code, if you forget to put the instance in a using statement, it will compile and run and you may simply not notice anything wrong. With my modifications, if you forget to put the instance in a using statement, the finalizer will execute when the RAII guard is garbage collected and in debug builds generate an error message at runtime and offer to break into the code in the debugger. My modifications were made only to make it harder to not use the RAII guard in the "one intended and right way", as you wrote, without it being detected. As to whether it should call the dispose method in the finalizer or not, that can be disputed - it's an error situation and if it hadn't been a finalizer I would have thrown an exception there instead of calling Debug.Fail. As it is I think it should fall under undefined behavior but if such a bug do creeps into a release version it might be better to call the cleanup action than to simply ignore it. However that is of course situation dependent. Sometimes it would make more harm than good.
Being able to dispose an instance more than once without anything bad happening is not really important, especially as the class implements IDisposable explicitly and is intended to be used only in using statements, but I thought it wouldn't hurt to add it. The documentation for IDisposable.Dispose does specify that you should be able to call the method more than once, but subsequent calls should be ignored.
Generalthanks for sharing - have 5 PinmemberPranay Rana17-Jan-11 2:24 
GeneralMy vote of 5 PinmemberWizzard01-Nov-10 19:02 
GeneralRAII-guarding fields in Pinmembersupercat931-Oct-10 20:54 
GeneralMy vote of 5 PinmemberJohn Brett28-Oct-10 6:21 
GeneralRe: My vote of 5 PinmemberRoberto Collina29-Oct-10 0:42 
GeneralRe: My vote of 5 PinmemberAndreas Gieriet29-Oct-10 1:53 
GeneralMy vote of 1 PinmemberJohn Simmons / outlaw programmer28-Oct-10 6:06 
GeneralRe: My vote of 1 PinmemberNemanja Trifunovic28-Oct-10 6:10 
GeneralRe: My vote of 1 PinmemberJohn Simmons / outlaw programmer28-Oct-10 7:17 
GeneralRe: My vote of 1 PinmemberNemanja Trifunovic28-Oct-10 7:50 
GeneralRe: My vote of 1 PinmemberAndreas Gieriet28-Oct-10 23:16 
GeneralRe: My vote of 1 PinmemberAndreas Gieriet28-Oct-10 23:23 
GeneralNice... PinmemberNemanja Trifunovic28-Oct-10 5:32 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.150327.1 | Last Updated 29 Oct 2010
Article Copyright 2010 by Andreas Gieriet
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid