Below is my code snippet, the variable "_lastError" doesn't seem to persist after it is set then accessed elsewhere.
Can anyone give a heads up on what I missed or done incorrectly? I've debugged the program, setting a breakpoint at both the getter and the private setter. Nothing else seems to be accessing nor modifying the value of "_lastError" other than where it was intended to.
class Utils
{
private static string _lastError;
public static string LastError
{
get
{
string lastError = Utils._lastError;
Utils._lastError = string.Empty;
return lastError;
}
private set
{
Utils._lastError = value;
}
}
public static void Foo()
{
try { // .... // }
catch (Exception ex)
{
Utils.LastError = ex.Message;
}
}
}
If the intended behavior is to hold the last error until it's accessed once, then the way you describe it acting is expected.
If the intended behavior is to hold onto the last error until another newer error overwrites it, James's point is important to remember. You're clearing the static value once it's accessed, which as Patrick pointed out affects your view in the debugger. The debugger enumerates all properties, because properties aren't intended to have side effects like wiping out the data that backs them.
Related
After reading this Eric Lippert Article, I understand that the C# compiler doesn't like it if we leave local variables uninitialized.
As I encounter this 'problem' from time to time, I looked at some of my old code and was able to weed out most of the situation where actually don't need uninitialized (SomeClass obj = null) local variables.
But I came up with a situation where I don't know how to refactor the code.
public void DoSomething(string foo) {
SomeClass obj; // = null;
try {
obj = SomeClass.CreateItem(target);
} catch(CustomException ex) {
// notify UI of error
}
if (obj != null) {
// do something with `obj`
}
}
SomeClass.CreateItem may fail due to external factors. If it does, I want to notify the user, if not I want to perform an Action.
The C# compiler doesn't want me to leave obj uninitialized, so I usually assign null to it.
This feels like a 'hack' now and my question is:
Is there a design flaw in the code above?
And if there is, how should I deal with references at compile time, when I can't determine if they are going to point to an existing object at run time?
I would refactor the code like this:
private SomeClass TryToCreateItem()
{
try
{
return SomeClass.CreateItem(target);
}
catch(CustomException ex)
{
// notify UI of error
}
return null;
}
public void DoSomething(string foo)
{
SomeClass obj = TryToCreateItem();
if (obj != null) {
// do something with `obj`
}
"Extract method" is my favourite refactoring.
The // do something withobj`` code should be inside the try block`.
What you're trying to do is run some code that may or may not succeed, and then run some other code only if the previous code succeeded. That's generally a very strong sign that the other code is a part of the same logical block that is dependent on there not being an exception. If there's an exception constructing this object you want this code to be skipped, which is exactly the behavior that you get by including it in the try block.
You could refactor it to encapsulate all your code within the try/catch related to that object and if you really do need to do something if it fails then you can use a bool to relate that to the rest of your code:
public void DoSomething(string foo)
{
bool failedCreation = false;
try
{
SomeClass obj = SomeClass.CreateItem(target);
}
catch (CustomException ex)
{
// notify UI of error
failedCreation = true;
}
if (failedCreation)
{
// do other stuff.
}
}
But this doesn't look like what you have in mind. I would just encapsulate everything within the try/catch and be done with it.
Hi I have a possible design flaw and i need to solve it with an extension method.
Lets say I have a class and it has a property of StringCollection. Example code
public class MyProblematicClass
{
public IDbAccess Db{get;set;}
public StringCollection Errors{get;set;}
public MyProblematicClass(IDbAcces db){ Db=db;}
public int SetItem(Item i)
{
var id = Db.Save(i);
this.Errors = Db.Erros;
return id;
}
}
What I am doing is, in my unit test class I mock IDbAccess. This class validates object according to attributes. If any error occures it doesnt hit to db, it just fills its own Errors collection. For unit test I use another dbclass which just runs validation routines and here is problem i cannot get Error. Let me give you example for further understanding ( I know design is problematic, but for now I want to deal with it without changing anything)
public static class MyDbExtension
{
public static Save(Item i)
{
Validation v = new Validation();
var erros = v.ValidateObject(i);
//Here is problem i cannot pass it to MyProblematicClass
if ( errors.Count > 0 )
return -1;
else
return 1;
/* what I want to is :
var stackTrace = new StackTrace(); get stack trace
var object = stackTrace.GetFrame(1).GetMethod().GetObject() or sth like that. get object
object.GetProperties()[0].SetValue(object,errors,null); find property and set it.
*/
}
}
in my unit test :
public class UnitTest
{
Mock<IDbAccess> _db ;
MyProblematicClass _mpc;
pubic Setup()
{
_db.Setup(x=>x.Save(It.IsAny<Item>).Returns(u =>MyDbExtension.Save(u));
_mpc = new MyProblematicClass(_db.Object);
}
public void SetItem_EmptyObject_Contains3Erros()
{
Item i = new Item();
_mpc.SetItem(i);
//At this point i cannot set _mpc.Errors
}
What I want to achieve is in my DbExtension class can I access caller class and set its Errors property? I tried but it wasn unlikely yet. If anyone has any decent solution I will be appreciative and of course you can comment on design problems.
Edit
I appreciate Alex's answer he just said ignore Save method just mock Erros property and it will be ok. That make sense but what I wonder is in question, is it possible to access Stack Trace and manipulate caller methods object's property?
Thanks in advance.
You need to setup the return value of _db.Errors, something like this:
public class UnitTest
{
Mock<IDbAccess> _db ;
MyProblematicClass _mpc;
StringCollection errors;
pubic Setup()
{
_db.Setup(x=>x.Save(It.IsAny<Item>).Returns(u =>MyDbExtension.Save(u));
_db.Setup(x=>x.Errors).Returns(errors);
_mpc = new MyProblematicClass(_db.Object);
}
public void SetItem_EmptyObject_ContainsError()
{
errors.Add("Expected Error!");
Item i = new Item();
_mpc.SetItem(i);
Assert.AreEqual("Expected Error!", _mpc.Errors[0]);
}
}
I must admit I don't really follow your design, why are you using a static method for save? You could just as easily have the line:
_db.Setup(x=>x.Save(It.IsAny<Item>).Returns(-1);
Then test IDbAccess.Save() independently.
In your 'extension' class the save method has no return value, and MyProblematicClass does not inspect the return value before assigning errors.
Not sure to fully understand the question, but you cannot access the parameters on the stack from a normal program. Runtime metadata is only about static information (method, properties, constants, etc...).
I believe only a debugger (which is considered as a special beast of its own) can do this without changing the program/source, and this has serious performance cost. As a side note, here is a link that explain how to build your own managed debugger (.NET 4): CLR Managed Debugger (mdbg) Sample 4.0
Another solution is to instrument your code (automatically or using a tool) to add some tracing call that can capture the list of parameters on each traced methods. Tools like PostSharp can do this. Here is another link: Non-Invasive Tracing & Logging
You could use unmanaged debugging API to access the call stack and get the object previous function on the stack was called on.
The problem is, the stack may not contain the method you are expecting. In cases such as inlining and tail call optimization, the call stack doesn't contain the previous method called, which means you can't reliably do what you want.
For more information see this answer by Eric Lippert.
This doesn't use the call stack, but might get you some mileage:
class CalledClass
{
public static void PokeCaller()
{
Program._this.Error = "Error!!!";
}
}
class Program
{
public string Error = null;
[ThreadStatic] public static Program _this;
public void Run()
{
_this = this;
CalledClass.PokeCaller();
Console.WriteLine(Error);
Console.ReadKey();
}
static void Main(string[] args)
{
Program p = new Program();
p.Run();
}
}
Making Errors be [ThreadStatic] might be a more direct way to do it... or some other variation on that theme. You might also combine it with stack trace checking to see if you were actually called by something that has "Errors" attribute before setting it...
I set up a simple program just to test how the code inside a get accessor executes (since I had been having some issues in another project), and found something quite strange:
class Program {
static void Main(string[] args) {
var test = new TestClass();
var testBool = test.TestBool;
}
}
public class TestClass {
private bool _testBool = true;
public bool TestBool {
get {
if (_testBool) {
Console.WriteLine("true!");
} else {
Console.WriteLine("false! WTF!");
}
_testBool = false;
return _testBool;
}
}
}
I expected the output to be
true!
But what I got instead was
true!
false! WTF!
Just what is going on here?
If I had to guess, I'd say that the debugger ran it once to show the members of a local variable in the IDE.
If you have side effects in properties (which you shouldn't), don't run it in the IDE :)
Try it at the console; it should behave itself there.
No repro.
And don't write Getters with side effects.
I'm using Compact Framework 3.5 / VS2008. I'm getting really odd behavior with TypeLoadException. The following code throws this error. The reason is a problem with the database connection. However for some unknown reason this inner exception is lost and is not contained in the TypeLoadException.
try
{
settingsFromDb = SettingsFromDbManager.Instance;
}
catch (Exception ex)
{
throw ex; // BREAKPOINT HERE
}
If we look at the SettingsFromDbManager class below it can be seen that it is a simple singleton class. The database error is occurring in the Load() method. I haven't included this code in the sample. If I put a breakpoint at the position indicated in the sample below I can see a database error. Unfortunately if I put a breakpoint in the position indicated in the code above then all I get is the TypeLoadException with no inner exception. There is nothing to indicate that a database problem occurred. This is bad :( Does anyone know why this strange behavior could be happening??
Cheers
Mark
public sealed class SettingsFromDbManager
{
static readonly SettingsFromDbManager _instance = new SettingsFromDbManager();
SettingsFromDbManager()
{
try
{
Load();
}
catch (Exception ex)
{
throw ex; // BREAKPOINT HERE
}
}
public static SettingsFromDbManager Instance
{
get
{
return _instance;
}
}
.... more code ...
}
** Update **
Thanks very much for all the great suggestions and help!
Pierre I used the test class you so kindly wrote. Here's the code I called it with. It must be a quirk of the Compact Framework I guess because when I examined the exception it was TypeLoadException with no inner exception :(
try
{
Fail.Test();
}
catch (Exception ex)
{
var x = ex.ToString(); // BREAKPOINT HERE
}
I think VinayC is probably correct about the reason. This is all a bit beyond my knowledge. Not sure what to do now. I don't want to give up my Singleton classes - they are useful. I'm using the "fourth version" Singleton pattern from http://csharpindepth.com/Articles/General/Singleton.aspx. I haven't used them before but seemed like a good idea to share the same instance of some utility classes around the application rather than creating and disposing them numerous times. Performance is a big issue with the Compact Framework.
* Update *
WOO HOO! All I had to do was change the Singleton class as follows. It instantiates the class in the property getter. Now my exceptions bubble to the surface as expected :)
public sealed class SettingsFromDbManager
{
static SettingsFromDbManager _instance = null;
SettingsFromDbManager()
{
try
{
Load();
}
catch (Exception ex)
{
throw new Exception("Error loading settings", ex);
}
}
public static SettingsFromDbManager Instance
{
get
{
if (_instance == null)
_instance = new SettingsFromDbManager();
return _instance;
}
}
.... more code ...
}
From what I know, static constructors may run on a different thread (or more specifically on different call chain) - its a guarantee from runtime that they will be invoked before type is accessed. Exception in the static constructor will mark type as not usable for the app domain. When type is accessed, you will get an TypeInitializationException (as per documentation) but exception occurred within type constructor will not come as inner exception because its not on same call chain - for that matter static constructor might had been executed quite before. Only puzzle out here is TypeLoadException instead of TypeIntializationException as Hans has pointed out.
Edit: Here's the article that explains lazy/eager semantics of type initializers. Your code can be eager implementation (i.e. static constructor may get invoked even before first access to type field)
There is no good reason why the exception raised in the static constructor would not show up in your original call location. However, I don't understand why you do not get the System.TypeInitializationException instead, which should be the exception thrown in case your static constructor fails.
Here is a piece of sample code which throws System.TypeInitializationException with an inner exception set to the "failed" exception:
class Fail
{
static Fail()
{
}
Fail()
{
throw new System.Exception ("failed");
}
static readonly Fail instance = new Fail ();
public static void Test()
{
}
}
I would investigate further to understand why you are getting a TypeLoadException instead, which should occur when an assembly cannot be properly loaded or initialized (TypeLoadException Class in MSDN).
In a C# app, suppose I have a single global class that contains some configuration items, like so :
public class Options
{
int myConfigInt;
string myConfigString;
..etc.
}
static Options GlobalOptions;
the members of this class will be uses across different threads :
Thread1: GlobalOptions.myConfigString = blah;
while
Thread2: string thingie = GlobalOptions.myConfigString;
Using a lock for access to the GlobalOptions object would also unnecessary block when 2 threads are accessing different members, but on the other hand creating a sync-object for every member seems a bit over the top too.
Also, using a lock on the global options would make my code less nice I think;
if I have to write
string stringiwanttouse;
lock(GlobalOptions)
{
stringiwanttouse = GlobalOptions.myConfigString;
}
everywhere (and is this thread-safe or is stringiwanttouse now just a pointer to myConfigString ? Yeah, I'm new to C#....) instead of
string stringiwanttouse = GlobalOptions.myConfigString;
it makes the code look horrible.
So...
What is the best (and simplest!) way to ensure thread-safety ?
You could wrap the field in question (myConfigString in this case) in a Property, and have code in the Get/Set that uses either a Monitor.Lock or a Mutex. Then, accessing the property only locks that single field, and doesn't lock the whole class.
Edit: adding code
private static object obj = new object(); // only used for locking
public static string MyConfigString {
get {
lock(obj)
{
return myConfigstring;
}
}
set {
lock(obj)
{
myConfigstring = value;
}
}
}
The following was written before the OP's edit:
public static class Options
{
private static int _myConfigInt;
private static string _myConfigString;
private static bool _initialized = false;
private static object _locker = new object();
private static void InitializeIfNeeded()
{
if (!_initialized) {
lock (_locker) {
if (!_initialized) {
ReadConfiguration();
_initalized = true;
}
}
}
}
private static void ReadConfiguration() { // ... }
public static int MyConfigInt {
get {
InitializeIfNeeded();
return _myConfigInt;
}
}
public static string MyConfigString {
get {
InitializeIfNeeded();
return _myConfigstring;
}
}
//..etc.
}
After that edit, I can say that you should do something like the above, and only set configuration in one place - the configuration class. That way, it will be the only class modifying the configuration at runtime, and only when a configuration option is to be retrieved.
Your configurations may be 'global', but they should not be exposed as a global variable. If configurations don't change, they should be used to construct the objects that need the information - either manually or through a factory object. If they can change, then an object that watches the configuration file/database/whatever and implements the Observer pattern should be used.
Global variables (even those that happen to be a class instance) are a Bad Thing™
What do you mean by thread safety here? It's not the global object that needs to be thread safe, it is the accessing code. If two threads write to a member variable near the same instant, one of them will "win", but is that a problem? If your client code depends on the global value staying constant until it is done with some unit of processing, then you will need to create a synchronization object for each property that needs to be locked. There isn't any great way around that. You could just cache a local copy of the value to avoid problems, but the applicability of that fix will depend on your circumstances. Also, I wouldn't create a synch object for each property by default, but instead as you realize you will need it.