I have a constructor for a class called ActNode which takes a class parameter called Act like this:
public Act Act; //the act affiliated with this node...
public ActNode(Act moAct, ...some others, not important) {
if (moAct == null)
throw new SomeException(); //this is never entered
Act = moAct;
... some other codes
}
The constructor above is the only constructor the ActNode has and anywhere in the code, the Act passed to the constructor is not null. Then, in one of the ActNode's methods, a bool flag of the Act is checked like this:
public void ActNodeMethod() {
if (Act.AnActFlagToBeChecked) { //FIXME this Act can be surprisingly null!
//do something
}
}
Thus, in a single thread environment, the Act.AnActFlagToBeChecked cannot throw NullException since the Act of an ActNode cannot be null. However, I use the ActNode in a multi-thread environment. It is not always, but sometimes the line above:
if (Act.AnActFlagToBeChecked) //FIXME this Act can be surprisingly null!
Can throw null exception.
Why is this so and how to fix it?
From reading a post in SO, it is said that this may happen if the Act is not initialized (therefore having default value of null) but the method is called. Yet in my implementation, there is no such case, because the Act everywhere in the code is never null when the constructor is called.
The only thing here is that I implement it in multi-thread environment where multiple ActNodes can call ActNodeMethod at the same time. But it shouldn't be a problem (or it could?) since each ActNode will have its own resource called Act associated to it (not a shared resource).
I am pretty confused here and would appreciate if someone can help enlightment me of the possible issues of the above implementation.
To give bigger context, ActNode is a TreeNode which I use to store a value representing the time needed to go to that node. I implement the ActNode in my searching tree algorithm to find the fastest solution to finish up a set of given "Acts". I use multi-threads because it can speed up the searching process.
Related
Suppose I have a class that provides some data to my application. Data initially comes from database, and I provide it through some methods that handle the whole database thing and present the result as a usable class instead of raw query result. This class has to do some setup (not complex) to make sure any method called can use the database (e.g. connect to database, make sure it contains some critical info, etc). So, were I to put it in a method (say, method Init(), that would handle checking for database, connecting to it, verifying that it does contain the info), I would have to make sure that this method is called before any other method.
So, I usually find that instead of doing this:
public class DataProvider
{
private SqlController controller;
public void Init()
{
controller = new SqlController();
controller.Init();
controller.ConnectToDataBase();
CheckForCriticalInfoInDatabase();
}
public Data GetData()
{
// get data from database (not actually going to use raw queries like that, just an example)
var queryResult = sqlController.RunQuery("SELECT something FROM SOME_TABLE");
// and present it as usable class
Data usefulData = QueryResultToUsefulData(queryResult);
return usefulData;
}
...
}
and then always making sure I call Init() before GetData(), i do something like
private SqlController _controller;
private SqlController controller
{
get
{
if (_controller == null)
{
_controller = new SqlController();
_controller.Init();
_controller.ConnectToDataBase();
CheckForCriticalInfoInDatabase();
}
return controller;
}
}
So, now i can be sure that i won't use an uninitialised SqlController, and I don't have to do that same null check in every method that uses it. However, I never noticed getters being used this way in other peoples' code.
Is there some pitfall I don't see? To me it looks like it's the same as lazy initialization, with the exception being that I use it not because the initialization is heavy or long, but because I don't want to check the order in which I call methods. This question points out that it's not thread-safe (not a concern in my case, plus I imagine it could be made thread-safe with some locks) and that setting the property to null will result in unintuitive behaviour (not a concern, because I don't have a setter at all and the backing field shouldn't be touched either way).
Also, if this kind of code IS bas practice, what is the proper way to ensure that my methods don't rely on order in which they are called?
As #madreflection said in the OP comments, use a method for anything that is possibly going to be slow. Getters and setters should just be quick ways of getting and setting a value.
Connections to dbs can be slow or fail to connect so you may have catches setup to try different connection methods etc.
You could also have the checking occur in the constructor of the object, that way the object cannot be used without init() being run in a different function, saving on time tracing where an error is actually occurring.
For example if you had one function create the object, do a bunch of 'stuff' then try to use the object without running init(), then you get the error after all of the 'stuff' not where you created the object. This could lead you to think there is something wrong in whatever way you are using the object, not that it has not been initialised.
I have a question regarding method calls and stack pointers.
Basically I have a program that reads input from the user. After creating an object of a class "Input", a method call "prompt()" presents a menu with choices, and each choice you make calls a new method that performs some operations. After making a choice, you can always choose to go back to the main menu, and this action calls "prompt()" again.
Now, my question is, will each call of "prompt()" point to a new place in the memory stack or will it enter the same context as when the first call was made? I.e is it possible to create a memory leak by going back to the main menu over and over?
class inOut {
public string[] Prompt(){
...
presentChoices();
...
}
private void PresentChoices(){
...
if(someChoice){
manualInput();
}
...
}
private void ManualInput(){
...
if(goBack){
Prompt();
}
...
}
}
I hope the question was clear and thanks in advance for any answers on this!
For each method you enter there should be a corresponding return. Otherwise it may lead to StackOverlow. It's not a new context, but a values left in stack, which are used for return to return to the point where method was called and for method call itself (to pass parameters).
To have something repeating itself you can use infinite loop:
while(true)
{
... // repeat this action
if(endcondition)
break;
}
In your case repeated action is call to prompt() to show menu. It may have return value to tell whenever repeat or exit, which you use in endcondition.
As Long as you call the method on the same object instance, it's going to be the same pointer to the same adress.
When you create new instances of an object each object has it's own pointer.
If you want to avoid that then you need to define the method as static. In this case you will call the method not from an instance but from the type.
Something you need to be careful about especially when you call the same method over and over again from the same instance context are recursive calls. To many recursive calls (many thousands) will result in a StackOverFlowException (like the Name of this website). You can find out if you have recursive calls in the StackTrace pane in Visual Studio or if you have Resharper installed it will tell you on the left side of the document.
Either way, what you are describing here is not really a "Memory Leak" (ML's are unused objects that do not get collected and stay in memory not doing anything) but rather a stack Overflow Situation.
Objects that are not referenced anymore are garbage collected.Thats what will happen to your Input object.
Unlesss...
... you do it wrong.
In Winform applications doing it wrong usually happens when there are eventhandlers involved that for some reason (the publisher of the event lives longer than the subscriber) prevent the garbage collection.
Suppose your code looks something like this:
void Prompt()
{
// ...
var obj = new Input();
// ...
if (someCondition)
{
Prompt(); // recursive
}
// ...
// Is 'obj' used here?
}
Then when you call Prompt() recursively, yes, a new context is created. The obj variable will point to a new object, etc.
If the recursion becomes very, very deep, you might get a StackOverflowException (no more space on the stack for new "call frames"), or you might get an OutOfMemoryException (no more heap space for Input instances).
However, if you know for some reason that the recursion will not become too deep, the Garbage Collector will clean things for you when it is safe to do so.
But maybe you should consider a while (or do) loop instead of having your method call itself? It really depends on what you want to achieve.
I may have misunderstood your question. Maybe Prompt() is not called from within Prompt itself? You should give simplified structure of your code (like my code sample above) to make it clear what calls what from where.
I have a class PluginProvider that is using a PluginLoader component to load plugins (managed/native) from the file system. Within the PluginProvider class, there is currently defined a property called 'PluginTypes' which calls the 'InitializePlugins' instance method on get().
class PluginProvider
{
IEnumerable<IPluginType> PluginTypes
{
get
{
//isInitialized is set inside InitializePlugins method
if(!isInitialized)
{
InitializePlugins(); //contains thread safe code
}
//_pluginTypes is set within InitializePlugins method
return _pluginTypes;
}
}
}
I am looking at refactoring this piece of code. I want to know whether this kind of initialization is fine to do within a property. I know that heavy operations must not be done in a property. But when i checked this link : http://msdn.microsoft.com/en-us/library/vstudio/ms229054.aspx , found this " In particular, operations that access the network or the file system (other than once for initialization) should most likely be methods, not properties.". Now I am a bit confused. Please help.
If you want to delay the initialization as much as you can and you don't know when your property (or properties) will be called, what you're doing is fine.
If you want to delay and you have control over when your property will be called the first time, then you might want to make your method InitializePlugins() public and call it explicitly before accessing the property. This option also opens up the possibility of initializing asynchronously. For example, you could have an InitializePluginsAsync()that returns a Task.
If delaying the initialization is not a big concern, then just perform the initialization within the constructor.
This is of course a matter of taste. But what i would do depends on the length of the operation you're trying to perform. If it takes time to load the plugins, i would create a public method which any user would need to call before working with the class. A different approach would be to put the method inside the constructor, but IMO constructors should return as quickly as possible and should contain field / property initialization.
class PluginProvider
{
private bool _isInitialized;
IEnumerable<IPluginType> PluginTypes { get; set;}
public void Initialize()
{
if (_isInitialized)
{
return;
}
InitializePlugins();
_isInitialized = true;
}
}
Note the down side of this is that you will have to make sure the Initialize method was called before consuimg any operation.
Another thing that just came to mind backing this approach is exception handling. Im sure you wouldn't want your constructorcto be throwing any kind of IOException in case it couldn't load the types from the file system.
Any initialization type of code should be done in the constructor, that way you know it will be called once and only once.
public class PluginProvider
{
IEnumerable<IPluginType> PluginTypes
{
get
{
return _pluginTypes;
}
}
public PluginProvider()
{
InitializePlugins();
}
}
What you are doing there is called lazy initialization. You are postponing doing a potentially costly operation until the very moment its output is needed.
Now, this is not an absolute rule. If your InitializePlugins method takes a long time to complete and it might impact user experience, then you can consider moving it into a public method or even making it asynchronous and call it outside of the property: at app startup or whenever you find a good moment to call a long-lasting operation.
Otherwise, if it's a short lived one-time thing it can stay there. As I said, not an absolute rule. Generally these are some guidelines for whatever applies to a particular case.
I am trying to find the right way to write code regarding checking for the invalid values. Invalid value, in my case, would be null. The thing with other questions in SO is that they fall under specific circumstances and I am interested in a more general solutions.
I have a code like this:
public class SomeClass
{
private readonly object m_internallyUsedObject;
private ThirdPartyObject m_user; // Third party object.
public SomeClass(object internallyUsedObject)
{
m_internallyUsedObject = internallyUsedObject; // We just want to ensure that the object will remain the same throught the life time of SomeClass object.
m_user = new ThirdPartyObject(); // This object is not yet needed here.
}
public void DoSomething()
{
m_user.DoSomethingElse(m_internallyUsedObject); // Now we're using it and we are not sure whether null value is tolerated.
}
}
Since we take the internallyUsedObject in constructor, we probably know the semantics of this object and how it should be used. On the other hand, we just relay this object to a third party object during calls.
Our SomeClass object will work just fine regardless of whether the value is null or not.
Now, the problem is that we do not know whether null will always work for the ThirdPartyObject - it might work in one version (in which case it's OK to omit null check) and do not work in another.
One could say that we should not care for checking for null if our class can handle it. But when I write the code documentation, I would like to tell the user the behavior and expectations of our own class.
As I mentioned above, this simple check might not be useful or even invalid in particular third party object's versions:
if (internallyUsedObject == null)
{
throw new ArgumentNullException("internallyUsedObject");
}
Is it valid according to the OOP to take the internallyUsedObject from the code above inside the constructor when we are not going to use it directly? Doesn't it violate the "fail fast" principle, since it might appear that we are just deferring the problem to the later stage of the object's life time?
As a rule I've tended to use the method you've described in the second code block, but in combination with sensible groupings of checks. By this I mean that certain checks for particular methods should be performed and actions taken before an logic is performed e.g.
public void MyMethod(MyObject input) {
// 1. perhaps security checks, if an in method security is required
if(security.AccessLevel < requiredLevel)
throw new CustomSecurityException("Insufficent Access");
// 2. data checks
if(input.Property == null)
throw new ArgumentNullException("Input didn't contain the value I wanted");
if(input.Property2 < someImportantLevel)
throw new CustomBLException("Input didn't meet required level for something");
// 3. perform BL
// ...do whatever
}
It's probably not ideal and often things like method attributes could be used for the security side of things but in quite a few of our apps this has seemed like a sensible grouping of checks. You know that all the checks are done up front rather than lengthy blocks like this:
if(input != null) {
//do logic
} else {
throw new Exception();
}
Where the checks could be hidden or nested and harder to locate.
I have a piece of software written with fluent syntax. The method chain has a definitive "ending", before which nothing useful is actually done in the code (think NBuilder, or Linq-to-SQL's query generation not actually hitting the database until we iterate over our objects with, say, ToList()).
The problem I am having is there is confusion among other developers about proper usage of the code. They are neglecting to call the "ending" method (thus never actually "doing anything")!
I am interested in enforcing the usage of the return value of some of my methods so that we can never "end the chain" without calling that "Finalize()" or "Save()" method that actually does the work.
Consider the following code:
//The "factory" class the user will be dealing with
public class FluentClass
{
//The entry point for this software
public IntermediateClass<T> Init<T>()
{
return new IntermediateClass<T>();
}
}
//The class that actually does the work
public class IntermediateClass<T>
{
private List<T> _values;
//The user cannot call this constructor
internal IntermediateClass<T>()
{
_values = new List<T>();
}
//Once generated, they can call "setup" methods such as this
public IntermediateClass<T> With(T value)
{
var instance = new IntermediateClass<T>() { _values = _values };
instance._values.Add(value);
return instance;
}
//Picture "lazy loading" - you have to call this method to
//actually do anything worthwhile
public void Save()
{
var itemCount = _values.Count();
. . . //save to database, write a log, do some real work
}
}
As you can see, proper usage of this code would be something like:
new FluentClass().Init<int>().With(-1).With(300).With(42).Save();
The problem is that people are using it this way (thinking it achieves the same as the above):
new FluentClass().Init<int>().With(-1).With(300).With(42);
So pervasive is this problem that, with entirely good intentions, another developer once actually changed the name of the "Init" method to indicate that THAT method was doing the "real work" of the software.
Logic errors like these are very difficult to spot, and, of course, it compiles, because it is perfectly acceptable to call a method with a return value and just "pretend" it returns void. Visual Studio doesn't care if you do this; your software will still compile and run (although in some cases I believe it throws a warning). This is a great feature to have, of course. Imagine a simple "InsertToDatabase" method that returns the ID of the new row as an integer - it is easy to see that there are some cases where we need that ID, and some cases where we could do without it.
In the case of this piece of software, there is definitively never any reason to eschew that "Save" function at the end of the method chain. It is a very specialized utility, and the only gain comes from the final step.
I want somebody's software to fail at the compiler level if they call "With()" and not "Save()".
It seems like an impossible task by traditional means - but that's why I come to you guys. Is there an Attribute I can use to prevent a method from being "cast to void" or some such?
Note: The alternate way of achieving this goal that has already been suggested to me is writing a suite of unit tests to enforce this rule, and using something like http://www.testdriven.net to bind them to the compiler. This is an acceptable solution, but I am hoping for something more elegant.
I don't know of a way to enforce this at a compiler level. It's often requested for objects which implement IDisposable as well, but isn't really enforceable.
One potential option which can help, however, is to set up your class, in DEBUG only, to have a finalizer that logs/throws/etc. if Save() was never called. This can help you discover these runtime problems while debugging instead of relying on searching the code, etc.
However, make sure that, in release mode, this is not used, as it will incur a performance overhead since the addition of an unnecessary finalizer is very bad on GC performance.
You could require specific methods to use a callback like so:
new FluentClass().Init<int>(x =>
{
x.Save(y =>
{
y.With(-1),
y.With(300)
});
});
The with method returns some specific object, and the only way to get that object is by calling x.Save(), which itself has a callback that lets you set up your indeterminate number of with statements. So the init takes something like this:
public T Init<T>(Func<MyInitInputType, MySaveResultType> initSetup)
I can think of three a few solutions, not ideal.
AIUI what you want is a function which is called when the temporary variable goes out of scope (as in, when it becomes available for garbage collection, but will probably not be garbage collected for some time yet). (See: The difference between a destructor and a finalizer?) This hypothetical function would say "if you've constructed a query in this object but not called save, produce an error". C++/CLI calls this RAII, and in C++/CLI there is a concept of a "destructor" when the object isn't used any more, and a "finaliser" which is called when it's finally garbage collected. Very confusingly, C# has only a so-called destructor, but this is only called by the garbage collector (it would be valid for the framework to call it earlier, as if it were partially cleaning the object immediately, but AFAIK it doesn't do anything like that). So what you would like is a C++/CLI destructor. Unfortunately, AIUI this maps onto the concept of IDisposable, which exposes a dispose() method which can be called when a C++/CLI destructor would be called, or when the C# destructor is called -- but AIUI you still have to call "dispose" manually, which defeats the point?
Refactor the interface slightly to convey the concept more accurately. Call the init function something like "prepareQuery" or "AAA" or "initRememberToCallSaveOrThisWontDoAnything". (The last is an exaggeration, but it might be necessary to make the point).
This is more of a social problem than a technical problem. The interface should make it easy to do the right thing, but programmers do have to know how to use code! Get all the programmers together. Explain simply once-and-for-all this simple fact. If necessary have them all sign a piece of paper saying they understand, and if they wilfully continue to write code which doesn't do anythign they're worse than useless to the company and will be fired.
Fiddle with the way the operators are chained, eg. have each of the intermediateClass functions assemble an aggregate intermediateclass object containing all of the parameters (you mostly do it this was already (?)) but require an init-like function of the original class to take that as an argument, rather than have them chained after it, and then you can have save and the other functions return two different class types (with essentially the same contents), and have init only accept a class of the correct type.
The fact that it's still a problem suggests that either your coworkers need a helpful reminder, or they're rather sub-par, or the interface wasn't very clear (perhaps its perfectly good, but the author didn't realise it wouldn't be clear if you only used it in passing rather than getting to know it), or you yourself have misunderstood the situation. A technical solution would be good, but you should probably think about why the problem occurred and how to communicate more clearly, probably asking someone senior's input.
After great deliberation and trial and error, it turns out that throwing an exception from the Finalize() method was not going to work for me. Apparently, you simply can't do that; the exception gets eaten up, because garbage collection operates non-deterministically. I was unable to get the software to call Dispose() automatically from the destructor either. Jack V.'s comment explains this well; here was the link he posted, for redundancy/emphasis:
The difference between a destructor and a finalizer?
Changing the syntax to use a callback was a clever way to make the behavior foolproof, but the agreed-upon syntax was fixed, and I had to work with it. Our company is all about fluent method chains. I was also a fan of the "out parameter" solution to be honest, but again, the bottom line is the method signatures simply could not change.
Helpful information about my particular problem includes the fact that my software is only ever to be run as part of a suite of unit tests - so efficiency is not a problem.
What I ended up doing was use Mono.Cecil to Reflect upon the Calling Assembly (the code calling into my software). Note that System.Reflection was insufficient for my purposes, because it cannot pinpoint method references, but I still needed(?) to use it to get the "calling assembly" itself (Mono.Cecil remains underdocumented, so it's possible I just need to get more familiar with it in order to do away with System.Reflection altogether; that remains to be seen....)
I placed the Mono.Cecil code in the Init() method, and the structure now looks something like:
public IntermediateClass<T> Init<T>()
{
ValidateUsage(Assembly.GetCallingAssembly());
return new IntermediateClass<T>();
}
void ValidateUsage(Assembly assembly)
{
// 1) Use Mono.Cecil to inspect the codebase inside the assembly
var assemblyLocation = assembly.CodeBase.Replace("file:///", "");
var monoCecilAssembly = AssemblyFactory.GetAssembly(assemblyLocation);
// 2) Retrieve the list of Instructions in the calling method
var methods = monoCecilAssembly.Modules...Types...Methods...Instructions
// (It's a little more complicated than that...
// if anybody would like more specific information on how I got this,
// let me know... I just didn't want to clutter up this post)
// 3) Those instructions refer to OpCodes and Operands....
// Defining "invalid method" as a method that calls "Init" but not "Save"
var methodCallingInit = method.Body.Instructions.Any
(instruction => instruction.OpCode.Name.Equals("callvirt")
&& instruction.Operand is IMethodReference
&& instruction.Operand.ToString.Equals(INITMETHODSIGNATURE);
var methodNotCallingSave = !method.Body.Instructions.Any
(instruction => instruction.OpCode.Name.Equals("callvirt")
&& instruction.Operand is IMethodReference
&& instruction.Operand.ToString.Equals(SAVEMETHODSIGNATURE);
var methodInvalid = methodCallingInit && methodNotCallingSave;
// Note: this is partially pseudocode;
// It doesn't 100% faithfully represent either Mono.Cecil's syntax or my own
// There are actually a lot of annoying casts involved, omitted for sanity
// 4) Obviously, if the method is invalid, throw
if (methodInvalid)
{
throw new Exception(String.Format("Bad developer! BAD! {0}", method.Name));
}
}
Trust me, the actual code is even uglier looking than my pseudocode.... :-)
But Mono.Cecil just might be my new favorite toy.
I now have a method that refuses to be run its main body unless the calling code "promises" to also call a second method afterwards. It's like a strange kind of code contract. I'm actually thinking about making this generic and reusable. Would any of you have a use for such a thing? Say, if it were an attribute?
What if you made it so Init and With don't return objects of type FluentClass? Have them return, e.g., UninitializedFluentClass which wraps a FluentClass object. Then calling .Save(0 on the UnitializedFluentClass object calls it on the wrapped FluentClass object and returns it. If they don't call Save they don't get a FluentClass object.
In Debug mode beside implementing IDisposable you can setup a timer that will throw a exception after 1 second if the resultmethod has not been called.
Use an out parameter! All the outs must be used.
Edit: I am not sure of it will help, tho...
It would break the fluent syntax.