try
                {
                    File.Delete(path);
                }
                catch (ArgumentException) { }
                catch (IOException) { }
                catch (UnauthorizedAccessException) { }

using (var t = TempData.CreateFile())
{
  ... // полезный код
} // пытаемся грохнуть файл

BRIAN GRUNKEMEYER Note that if your constructor throws an exception, the finalizer for your type will still run! So the finalizer and the Dispose(false) code path in your type must be prepared to handle an uninitialized state. Worse yet, if your app must deal with asynchronous exceptions such as ThreadAbortException or OutOfMemoryException, your finalizer may have to deal with partially initialized state if your constructor threw an exception halfway through! This surprising fact is usually pretty easy to deal with, but it may take you several years to realize it

AVOID throwing an exception from within Dispose(bool) except under critical situations where the containing process has been corrupted (leaks, inconsistentshared state, etc.).
Users expect that a call to Dispose will not raise an exception. For example, consider the manual try-finally in this snippet:

TextReader tr = new StreamReader(File.OpenRead("foo.txt")); try {
// do some stuff
}
finally {
tr.Dispose();
// more stuff
}

If Dispose could raise an exception, further finally-block cleanup logic will not execute.

S>using (var t = TempData.CreateFile())
S>{
S>  ... // полезный код
S>} // пытаемся грохнуть файл
S>

IEnumerable<T> items //100000 items

foreach(var item in items)
using (var t = TempData.CreateFile())
{
  ... // полезный код
} // пытаемся грохнуть файл

S>Вот как-то так. Если честно, этот код писался на автомате и проверки я ставил самые стандартные. Если есть идеи как сделать лучше — вэлкам!

try
{
  using (GempFile())
  {
    // Something throws Exception1
  } // Dispose() throws Exception2
}
catch (Exception ex)
{
  // Exception2 wins
}