Narrowed question:
I need to implement reusable functionality that initializes a temporary file, runs some custom logic provided by the user, and then deletes the file. I can do this either through a static utility method that takes the user's logic as a delegate, or through a class that implements IDisposable to perform cleanup during Dispose. The two approaches would be used as follows:
// Delegate-parameterized method approach:
TempFile.Using(filePath =>
{
// use temporary file here
});
// IDisposable implementation approach:
using (var tempFile = new TempFile())
{
// use temporary file here
}
Which are the advantages and drawbacks to each approach? Which one should I use?
Original question:
I am developing some general-purpose functionalities that require a fixed “initialization – custom logic – clean-up” sequence. The clean-up must be performed as part of the same construct used for executing the operation; I don't want to confer the responsibility for calling a Cleanup or Close method to the user.
For example, I might want to provide functionality that automatically creates and deletes a temporary file. The simplest way to implement this is through a method that takes an Action<T> delegate:
public static void UsingTempFile(Action<string> action)
{
// initialization
string tempFilePath = Path.GetTempFileName();
try
{
action(tempFilePath);
}
finally
{
// clean-up
File.Delete(tempFilePath);
}
}
This could be used like so:
UsingTempFile(filePath =>
{
File.WriteAllText(filePath, "Hello world");
string text = File.ReadAllText(filePath);
});
However, this approach often requires me to implement four method overloads to support returned results and anonymous functions:
public static void UsingTempFile(Action<string> action) { /* ... */ }
public static TResult UsingTempFile<TResult>(Func<string, TResult> func) { /* ... */ }
public static async Task UsingTempFile(Func<string, Task> asyncAction) { /* ... */ }
public static async Task<TResult> UsingTempFile<TResult>(Func<string, Task<TResult>> asyncFunc) { /* ... */ }
The former three can implemented as simple wrappers that call the last overload. However, in a public API, they still need to be documented and unit-tested, substantially cluttering my codebase.
An alternative approach is to design an instantiatable class that implements IDisposable to represent the operation. This class would perform the initialization in its constructor, and the clean-up in its Dispose method. It could then be consumed like so:
using (var tempFile = new TempFile())
{
File.WriteAllText(tempFile.FilePath, "Hello world");
string text = File.ReadAllText(tempFile.FilePath);
}
The advantage of this approach is that the C# compiler automatically handles all my four cases ‒ the user can specify return and await keywords in the using block.
However, I often need to be able to throw exceptions from my clean-up logic – like IOException being thrown from File.Delete if the temporary file is still in use in the above example. The MSDN documentation for the Dispose Pattern states:
X AVOID throwing an exception from within Dispose(bool) except under critical situations where the containing process has been corrupted (leaks, inconsistent shared state, etc.).
Users expect that a call to Dispose will not raise an exception.
If Dispose could raise an exception, further finally-block cleanup logic will not execute. To work around this, the user would need to wrap every call to Dispose (within the finally block!) in a try block, which leads to very complex cleanup handlers.
A related question makes a stronger case about the downsides to throwing exceptions from finally blocks:
A first exception is thrown
A finally block is executed as a result of the first exception
The finally block calls a Dispose() method
The Dispose() method throws a second exception
[…] You lose information because .NET unceremoneously replaces the first exception with the second one. A catch block somewhere up the call stack will therefore never see the first exception. However, one is usually more interested in the first exception because that normally gives better clues as to why things started to go wrong.
This argument has merit – if the user's custom logic throws an exception, I would not want it to be hidden (and lost) by any exceptions thrown in the clean-up. There are solutions to this, such as Marc Gravell's wrapper for IDisposable objects (which swallows all Dispose exceptions), but this imparts more responsibility on the user. On the other hand, the .NET Framework Class Library itself seems to disregard this rule ‒ FileStream can throw exceptions from its Dispose method if it fails to flush the buffer's contents to disk.
Which of the two approaches (delegate-parameterized methods vs IDisposable) would be recommendable for these general-purpose implementations? Are there any implications apart from the ones mentioned above?
Update: This is an example of how delegate-parameterized methods can prevent main-logic exceptions from being swallowed:
public static void UsingTempFile(Action<string> action)
{
// initialization
string tempFilePath = Path.GetTempFileName();
bool isSuccess = false;
try
{
// main logic
action(tempFilePath);
isSuccess = true;
}
finally
{
try
{
// clean-up
File.Delete(tempFilePath);
}
catch
{
// only propagate exceptions from clean-up if there were
// no unhandled exceptions from the main logic
if (isSuccess)
throw;
}
}
}
Related
I recently ran into a problem where I was developing an API which talked to two data sources in some methods. The POST for a couple methods modified SQL data through the use of entity framework as well a data source using as an old SDK that was STA COM based. To get the STA COM SDK code to work correctly from within the API methods, I had to create method attributes that identified the methods as needing to be single threaded. I forced single threading by overriding the InvokeActionAsync() method from ApiControllerActionInvoker. If a method was not given an attribute to be single threaded, the overridden invoker simply used the normal base class InvokeActionAsync().
public class SmartHttpActionInvoker: ApiControllerActionInvoker
{
public override Task<HttpResponseMessage> InvokeActionAsync(HttpActionContext context, CancellationToken cancellationToken)
{
// Determine whether action has attribute UseStaThread
bool useStaThread = context.ActionDescriptor.GetCustomAttributes<UseStaThreadAttribute>().Any();
// If it doesn't, simply return the result of the base method
if (!useStaThread)
{
return base.InvokeActionAsync(context, cancellationToken);
}
// Otherwise, create an single thread and then call the base method
Task<HttpResponseMessage> responseTask = Task.Factory.StartNewSta(() => base.InvokeActionAsync(context, cancellationToken).Result);
return responseTask;
}
}
public static class TaskFactoryExtensions
{
private static readonly TaskScheduler _staScheduler = new StaTaskScheduler(numberOfThreads: 1);
public static Task<TResult> StartNewSta<TResult>(this TaskFactory factory, Func<TResult> action)
{
return factory.StartNew(action, CancellationToken.None, TaskCreationOptions.None, _staScheduler);
}
}
public static void Register(HttpConfiguration config)
{
....
config.Services.Replace(typeof(IHttpActionInvoker), new SmartHttpActionInvoker());
...
}
This worked well until I noticed something odd. My Logging database was logging duplicate records when a method NOT marked as single threaded was throwing a HttpResponseException back to the client. This behavior did not exist when the same method returned OK().
Debugging, I noticed the code execute in the API method, then reach the throw statement. The next line after the exception was thrown to be shown in debugger was the InvokeActionAsync() code I wrote. Following this the method was run again, in full, hitting the thrown exception, the action invoker, and then returning the result to the client. Effectively, it appears my use of overriding the InvokeActionAsync causes the Action invoker to be called twice somehow... but I am not sure how.
EDIT: Confirmed that the System.Threading.Thread.CurrentThread.ManagedThreadId for the current thread when it is thrown and logged is different for each execution of the API method. So, this reinforces my belief two threads are being created instead of one. Still not sure why.
Anyone have any experience with overriding the InvokeActionAsync behavior that might be able to explain this behavior? Thanks!
I want to encapsulate the process of unzipping a zip file, making the files available for use, and then automatically cleaning them up when they are no longer needed. I did this with a class that implements the IDisposable interface, so that I can instantiate it with "using" and the files will be cleaned up when going out of scope, eliminating the need to specifically delete the files. The class, TempUnzip, can therefore be used thus:
static void AccessZipFileContents(string zipFilePath)
{
using (var temp = new TempUnzip(zipFilePath)
{
var tempPath = temp.TempPath;
if (tempPath != null)
{
// read/use the files in tempPath
}
} // files automatically get deleted when it goes out of scope! Woohoo!
}
Here is the implementation of the TempUnzip class:
using System.IO;
using System.IO.Compression;
public class TempUnzip : IDisposable
{
public TempUnzip(string zipFilePath)
{
try
{
var tempFolderName = Path.GetRandomFileName();
var tempFolder = Path.GetTempPath();
var tempPath = Path.Combine(tempFolder, tempFolderName);
Directory.CreateDirectory(tempPath);
ZipFile.ExtractToDirectory(zipFilePath, tempPath);
TempPath = tempPath;
}
catch (Exception) { TempPath = null; }
}
public readonly string TempPath;
public void Dispose()
{
try
{
if (TempPath != null)
Directory.Delete(TempPath);
}
catch (Exception) { }
}
}
Is this a valid use of IDisposable?
If so, do I need to implement the full standard IDisposable pattern?
If not, is there a better way to encapsulate the creation and destruction of files in such a way that they're tied to the lifetime of an object, or should I avoid this altogether?
Is this a valid use of IDisposable?
From the documentation:
Provides a mechanism for releasing unmanaged resources.
Files on local disk are certainly unmanaged resources. Thus, this use fits with the stated purpose of IDisposable.
If so, do I need to implement the full standard IDisposable pattern?
You can. The usual cautions about finalizers need to be considered, but you already linked to those. It certainly won't hurt.
If not, is there a better way to encapsulate the creation and destruction of files in such a way that they're tied to the lifetime of an object, or should I avoid this altogether?
I also like a functional approach for this kind of problem. That would make your example look something like this:
static void AccessZipFileContents(string zipFilePath)
{
ZipManager.RunWithZipExtracted(zipFilePath, (string tempPath) =>
{
if (tempPath != null)
{
// read/use the files in tempPath
}
} // files automatically get deleted when it goes out of scope! Woohoo!
}
//from ZipManager.cs...
static void RunWithZipExtracted(string zipLocation, Action<string> toRun)
{
var tempPath = CalculateTempPath();
try
{
ExtractZip(zipLocation, tempPath);
toRun(tempPath);
}
finally
{
DeleteFolder(tempPath);
}
} //private methods left as exercise for the reader
A pattern like that avoids the problem of "what if they don't call Dispose?" entirely.
This is a situation where having a finalizer is probably a good idea, but the MS pattern is predicated on the idea of public objects having finalizers, which is almost always a bad idea. Instead, resources that will require finalization-based cleanup should be encapsulated in privately-held objects whose references are never exposed to the outside world. Because the inner objects are private, there's no need for them to use the IDisposable pattern--instead they may be designed in whatever fashion best fits the requirement.
Since trying to close a file handle more than once may have catastrophic consequences, and it's possible (though rare) for a finalizer to execute while other code is using an object (or even performing Dispose upon it!), writing a robust class can be difficult. A nasty issue that arises is that file accesses can block but finalizer actions shouldn't. One could work around that by creating a thread whose purpose was to wait until the file is supposed to be closed and deleted, and which would then close and delete the file. Even if the attempt to delete the file gets blocked, other finalizer actions could continue apace. Unfortunately, eagerly creating a thread for the purpose of allowing safe finalizer-based cleanup is apt to be a waste of resources, but thread creation seems like an excessively-heavyweight task to be performing within a finalizer. I don't know what the best solution is.
In this instance I would say that it is a good example of IDisposable, if Dispose isn't called straight away that you've finished using it then it's not the end of the world and quickly calling this for the same zip file wouldn't cause an exception as you're using unique temp folders each time; which again you're not leaving file pointers left open on the files, etc. The only issue I could see is that if disk space was really tight you might want to expose the delete folder as a method to allow the option of that being called directly and then Dispose is just used to clean up after for all cases.
Note: in this example you probably want to call Directory.Delete(TempPath, true); because the method you're calling will throw an IOException if the folder isn't empty (something your catch will hide) - see https://msdn.microsoft.com/en-us/library/62t64db3%28v=vs.110%29.aspx
I need to call several methods from an external framework - or rather I am writing a wrapper around it for other users to call methods from this framework in a non-predetermined order. Now some methods of the framework will throw exceptions, even though no "real" error occured. Basically they are supposed to be internal exceptions just to notify whoever that the action to be performed has already been performed before. For example: that a file has been loaded. It wont hurt to load the file another time, so for all I care this "error" is no error at all. So I need to continue on this exception, but I also need to catch other, real exceptions, such as when the framework, which connects to clients and stuff, cannot do so.
Below I have some (extremely simplified) example code. Obviously that code wont compile because the code for the custom exceptions is missing. Also in real life the code is spread over three assemblies. This means, that I cannot wrap the exception handler around those framework methods which will throw InternalFrameworkException() only. I can only wrap it around the whole SomeMethod(). As I wrote, this is an extremely simplified example.
Is there any way to handle the RealException()s but continue the InternalFrameworkException()s without using PostSharp as mentioned here? Note that this is not about letting the InternalFrameworkException() fall through, but they should actually not break out of the try{} block at all.
namespace ExceptionTest
{
using System;
internal class Program
{
private static void Main(string[] args)
{
try
{
SomeMethod();
}
catch (InternalFrameworkException exception)
{
// Do not actually catch it - but also dont break the
// execution of "SomeMethod()".
// Actually I never want to end up here...
}
catch (RealException exception)
{
// Break the execution of SomeMethod() as usual.
throw;
}
catch (Exception exception)
{
// Again, break the execution of SomeMethod() as usual.
throw;
}
finally
{
// Clean up.
}
}
#region == Method is actually contained in another assembly referencing this assembly ===
private static void SomeMethod()
{
// Should break if uncommented.
// MethodThrowingProperException();
// Should not break.
MethodThrowingInternalExceptionOrRatherContinuableError();
// Should execute, even if previously an internal framework error happened.
MethodNotThrowingException();
}
#endregion
#region ===== Framework methods, they are contained in a foreign dll =====
private static void MethodThrowingProperException()
{
// Something happened which should break execution of the
// application using the framework
throw new RealException();
}
private static void MethodThrowingInternalExceptionOrRatherContinuableError()
{
// Perform some stuff which might lead to a resumable error,
// or rather an error which should not break the continuation
// of the application. I.e. initializing a value which is
// already initialized. The point is to tell the application using
// this framework that the value is already initialized, but
// as this wont influence the execution at all. So its rather
// a notification.
throw new InternalFrameworkException();
}
private static void MethodNotThrowingException()
{
// Well, just do some stuff.
}
#endregion
}
}
Edit: I did try the example in the post I already linked above, and it works like a charm ... when using it in SomeMethod() only. I could theoretically implement this as I am wrapping all the methods that are called in SomeMethod() before exposing them to the final assembly, but I dislike this approach, because it will give my code unnessessary complexity.
When an exception is thrown, the execution flow is broken. You can catch the exception or not but you cannot "continue" after the exception is thrown.
You can split your logic into parts and continue to the next part when one throws an exception, though.
I'm not sure of a way apart from an AOP approach in this case. Given that you are unable to change SomeMethod() or any of the methods it calls, you will need to look at adorning the called methods like MethodThrowingInternalExceptionOrRatherContinuableError() with an aspect that catches the 'continuable' exceptions.
The aspect would effectively wrap the method call in a try{...} catch(InternalFrameworkException) (or similar catchable exception) block.
As you have already noted, you are unable to drop back into a method once it has thrown an exception, even if the caller catches the exception in a catch() block, so you need to inject into the methods you are calling, which an AOP framework like PostSharp will allow you to do.
I have solved similar problem by wrapping the calls to InternalFrameworkMethod() in try-catch(InternalFrameworkException) blocks and calling it somethig like InternalFrameworkMethodSafe() and then in SomeMethod call the treated InternalFrameworkMethodSafe().
void InternalFrameworkMethodSafe()
{
try
{
InternalFrameworkMethod();
}
catch(InternalFrameworkException e)
{
Trace.Write("error in internal method" + e);
}
}
void SomeMethod()
{
...
InternalFrameworkMethodSafe();
...
}
It may not work in your case if the internal framework is in wrong state and not able to continue.
I have a very simple logging mechanism in my application which periodically writes a line to a file (a logging library would be overkill for my needs) which looks something like this:
private string logfile = #"C:\whatever.log";
public void WriteLine(string line)
{
using(FileStream fs = File.Open(logfile, FileMode.Append))
{
// Log Stuff
}
}
So any time I call that method, a new FileStream is created and disposed after logging is finished. So I considered using an already instantiated object to prevent the continuous creation of new objects:
private string logfile = #"C:\whatever.log";
private FileStream myStream = File.Open(logfile, FileMode.Append);
public void WriteLine(string line)
{
using(myStream)
{
// Log Stuff
}
}
However, the MSDN reference discourages this (last example), due to scope issues.
What does one do in that case? Is the overhead in my first example negligible?
The using statement doesn't do anything else than calling the Dispose() method of the object.
So considering your second example, after the first call to the WriteLine(string) method the filestream is disposed. So any other call, after the first one, to this Method will result in an exception.
Using the File.AppendText() method like Chris had suggested in the comment would be a way to go. But keep in mind, that using this or any other File... method will also open a stream and close and dispose it afterwards.
It will just result in less code.
The second approach does also dispose the stream every time you call WriteLine since you are also using the using-statement. MSDN discourages from this approach because the variable myStream does still "exist" even if the object is disposed. So that is more error-prone.
If you often need to use this method you should cosider to use the using "outside" or use a try-catch-finally:
var myLogger = new MyLogger();
try
{
// here is your app which calls myLogger.WriteLine(...) often
}
catch(Exception ex)
{
// log it
}
finally
{
myLogger.Dispose(); // myLogger is your Log class, dispose should call myStream.Dispose();
}
The overhead might not be negligible, but that might be beside the point.
When you are using using, the creation, acquisition of resource and the disposing of the used resources is nicely scoped. You know where it starts, where it's used, and where it's finished.
If you go for the second scenario, you know where it starts (it's when the containing class is created), but after that, you have no platform-guaranteed way to control where it's used, and where (if at all) the resources are disposed.
You can do this yourself if this is critical code, and your containing class implements the IDisposable pattern properly, but this can be tricky and not for the faint of heart :)
However, you stated in the question "a logging library would be overkill for my needs", so I think you are fine with the minimal overhead. IMHO, you should be fine with one of the ready-made File methods, like File.AppendAllText:
public void WriteLine(string line)
{
//add an enter to the end
line += Environment.NewLine;
File.AppendAllText(logfile, line);
}
or File.AppendAllLines:
public void WriteLine(string line)
{
File.AppendAllLines(logfile, new []{line});
}
I've got a method that does some IO that generally looks like this:
public bool Foo()
{
try
{
// bar
return true;
}
catch (FileNotFoundException)
{
// recover and complete
}
catch (OtherRecoverableException)
{
// recover and complete
}
catch (NonRecoverableException ex)
{
ExceptionPolicy.HandleException(ex, "LogException");
return false;
}
}
The method isn't mission critical to be completed, there are external recovery steps - and it's relatively common for NonRecoverableException to be thrown - it's in the spec for it to return false, report 'cannot be completed at this time' and processing moves along. A NonRecoverableException does not put the program in an invalid state.
When I'm unit testing, and one of these exceptions is thrown, I get the error that
Activation error occured while trying to get instance of type ExceptionPolicyImpl
And I'd like to suppress that in favor of getting the actual/original exception information instead of EntLib not being able to log (and, indeed to force the NonRecoverableException and have an [ExpectedException(typeof(NonRecoverableException))] unit test to ensure that this method complies with the spec.
How might I go about that?
edit
Using preprocessor directives is not ideal as I hate seeing test-specific code in the codebase.
Testability of your code using the Entlib static facades is difficult. Without changing your code a little, your only answer is to add an app.config file to your test assembly and set up the Entlib exception block with an innocuous policy that does nothing.
However, in Entlib 4 (and 5, which I see you're using) there's another way. We added an instance entry point to all the blocks specifically to improve the testability story. For the exception block, that instance is the ExceptionManager. Using it is pretty simple. Get an exception manager instance into your type, and then call it instead of ExceptionPolicy. Something like this:
public class Whatever {
private ExceptionManager exm;
public Whatever(ExceptionManager exm) { this.exm = exm; }
public bool Foo() {
try {
... do whatever ...
}
catch(NonRecoverableException ex) {
exm.HandleException(ex, "LogException");
return false;
}
}
}
Now that you've got that in there, you can mock out the ExceptionManager (it's an abstract base class) to essentially no-op it during test, either manually or using a mock object framework.
If you don't want to force your users to use a DI container, you can add a default constructor that gets the current exception manager:
public class Whatever {
private ExceptionManager exm;
public Whatever() : this(EnterpriseLibraryContainer.Current.GetInstance<ExceptionManager>()) { }
public Whatever(ExceptionManager exm) { this.exm = exm; }
}
End users use the default constructor, your tests use the one that takes in an explicit ExceptionManager, and you have your hook to mock out anything Entlib uses.
All the blocks now have these "Manager" classes (where they make sense, anyway).
Hmm, you could refactor the code to place everything in the try block in a separate method and configure you tests to call that instead of the existing method?