|
|
Only when it's available.
Or, if you want the Exception to be thrown. Why avoid the Exception if you're just going to throw your own anyway?
|
|
|
|
|
PIEBALDconsult wrote: Only when it's available.
thats what i said  (if the method is there...)
Now why would you even consider raising/throwing an exception, thats just bad pratice. never use exception for you code-flow.
An exception should only be thrown, when it truly is an exception, like if your transfer data over the net and the cord gets unplugged, thats an exception.
Parsing data that is not correct, is not an exception.
Lets say in this case, you want to parse -002 to -2, and the value begin parsed, turns out to be "-002$" then its not an exception, then the value ("you should know"), you want to parse is incorrect, handle it. thats to correct way, I believe.
Furthermore, I believe the code engine will spin down for every exception it has to handle.
Just a short comparison:
for 1000 parsings
Parse: 4078 milliseconds
Try Parse: 0 milliseconds
I used this code to test:
Stopwatch sw = new Stopwatch();
sw.Start();
for (int i = 0; i < 1000; i++)
{
try { int demo = int.Parse("x"); }
catch (Exception) {}
}
sw.Stop();
Debug.WriteLine("Parse: " + sw.ElapsedMilliseconds);
sw.Reset();
sw.Start();
for (int i = 0; i < 1000; i++)
{
int demo;
int.TryParse("x", out demo);
}
sw.Stop();
Debug.WriteLine("Try Parse: " + sw.ElapsedMilliseconds);
With great code, comes great complexity, so keep it simple stupid... 
|
|
|
|
|
Paw Jershauge wrote: thats just bad pratice
Only at the application level, not at the framework level.
|
|
|
|
|
Also on framework level, Microsoft contradicts its self sometimes in the framework, but hey I dont always follow my own guidelines either.
- If you know the Error, of why the code fails, handle it.
- Only handle exceptions you can recover from.
- If you dont know why the exception was thrown, its better to let the framework kill your app. According to microsoft.
But then again others think you should clean up what you can, and then exiting the orderly fashion.
With great code, comes great complexity, so keep it simple stupid...
|
|
|
|
|
Paw Jershauge wrote: why the code fails, handle it.
Some times you want to handle it by exiting.
Paw Jershauge wrote: you can recover from
Correct.
Paw Jershauge wrote: its better to let the framework kill your app
Yes, quite often, but that's up to the application, not any underlying code.
But keep in mind that I write mostly console/batch programs and Windows Services.
|
|
|
|
|
Paw Jershauge wrote: Try Parse: 0 milliseconds
You don't find that a little suspicious? I expect the whole for loop got optimized away, I've had that happen before. Try summing up the values and print the sum after the loop to ensure that it doesn't it doesn't get optimized.
Paw Jershauge wrote: catch (Exception) {}
I certainly didn't suggest that.
Paw Jershauge wrote: int.Parse("x");
That's just silly.
|
|
|
|
|
PIEBALDconsult wrote: You don't find that a little suspicious? I expect the whole for loop got optimized away, I've had that happen before. Try summing up the values and print the sum after the loop to ensure that it doesn't it doesn't get optimized.
Actualy you might be right about the optimizing, but the fact is that the code is an will be faster running TryParse.
PIEBALDconsult wrote: Paw Jershauge wrote:
catch (Exception) {}
I certainly didn't suggest that.
i didn't say you did. this was only a very very short demo test.
PIEBALDconsult wrote: Paw Jershauge wrote:
int.Parse("x");
That's just silly.
No not really, as my p.o.i. was to fail anyway.
Stopwatch sw = new Stopwatch();
int ParseOutPut = 0;
sw.Start();
for (int i = 0; i < 1000; i++)
{
try
{
int demo = 0;
if(i % 3 == 0)
demo = int.Parse("x");
else
demo = int.Parse("1" + i.ToString());
ParseOutPut += demo;
}
catch (Exception) { }
}
sw.Stop();
Debug.WriteLine("Parse [" + ParseOutPut + "]: " + sw.ElapsedMilliseconds);
sw.Reset();
int TryParseOutPut = 0;
sw.Start();
for (int i = 0; i < 1000; i++)
{
int demo;
if(i % 3 == 0)
int.TryParse("x", out demo);
else
int.TryParse("1" + i.ToString(), out demo);
TryParseOutPut += demo;
}
sw.Stop();
Debug.WriteLine("Try Parse [" + TryParseOutPut + "]: " + sw.ElapsedMilliseconds);
Returns on my computer:
Parse [938727]: 1464 ms
Try Parse [938727]: 0 ms
With great code, comes great complexity, so keep it simple stupid...
|
|
|
|
|
Parse: 16016 500000000
Try Parse: 15440 500000000
About a four percent saving, big deal, it's not about performance anyway.
System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch() ;
int demo = 0 ;
sw.Start() ;
for ( int i = 0 ; i < 100000000 ; i++ )
{
demo += int.Parse ( args [ 0 ] ) ;
}
sw.Stop() ;
System.Console.WriteLine ( "Parse: {0} {1}" , sw.ElapsedMilliseconds , demo ) ;
demo = 0 ;
sw.Reset() ;
sw.Start() ;
for ( int i = 0 ; i < 100000000 ; i++ )
{
int temp ;
int.TryParse ( args [ 0 ] , out temp ) ;
demo += temp ;
}
sw.Stop() ;
System.Console.WriteLine ( "Try Parse: {0} {1}" , sw.ElapsedMilliseconds , demo ) ;
|
|
|
|
|
Its all about performance, your code here assumes that everything is ok. so its not valid test.
With great code, comes great complexity, so keep it simple stupid...
|
|
|
|
|
If it fails, I want to throw and terminate.
|
|
|
|
|
I have a little issue and I know you will say that you always make sure the threads close. The problem I have is I spawn 3 threads to check for various information using WMI. The one thread that pulls applications can be time consuming and there really isn't a function to tell WMI to stop once it has started...
So a user selects a computer and tells it to open, when the other form for that specifc computer opens it begins pulling information. Basically I want the user to be able to close the form even if it is not finished. But I don't want it to cause the application to fail or they get a popup just because the thread couldn't write to the handle.
There has to be a way. I mean Windows does it. If you launch a application in debug mode and that application is running multiple threads, then you go to visual studio and tell it to stop debugging everythign quits with no errors!
I am creating the thread like this:
appThread = new Thread(new ThreadStart(GetApplications));
appThread.IsBackground = true;
appThread.Start();
GetApplications:
private void GetApplications()
{
WMI_Commands wmi = new WMI_Commands(Username, Password,
System.Management.ImpersonationLevel.Impersonate, System.Management.AuthenticationLevel.Default);
List<Product> products = wmi.InstalledApplications(NetBios);
foreach (Product p in products)
{
AddApplication(p);
}
products = null;
SetPBVisible("pbapplications", false);
}
|
|
|
|
|
Some times you just have to abort a thread. 
|
|
|
|
|
You can close the form all you want so long as your WMI retrieval code doesn't update a control on the form. Your code should be generating a liost of applications and populating a collection with that data, NOT a control on a form. This way, you've completely disconnected the data from the UI.
Your code can supply an event to signal the form code that the collection has been completely populated, then the form can bind the display control to that data collection. When the form closes, it can remove the handler it registered, so, when the event tries to fire, it sees that it has no subscribers and doesn't do anything.
In other words, you can leave the data collection code running and not worry about killing the thread and possibly screwing up WMI provider in the process.
|
|
|
|
|
Well this is "kind of" how I did it. I populated a List collection with the data. Once it finished it then ran a foreach on the List and then populated the controls. BUT I did this all within the spawned thread and not the main thread.
So you are saying populate a global List and somehow tell the main thread it is done then when the main thread sees that my spawned thread is completed the main thread then loops through teh collection to populate the data.
Right? I may need an short example to see this
|
|
|
|
|
I posted what I thought you meant below but was trying it out.. calilng that event from that thread puts it on the spawned thread.. Do you happen to know an example of what you mean?
|
|
|
|
|
Dave Kreskowiak wrote: leave the data collection code running and not worry about killing the thread
But what if the user is trying to exit the application, not just the form? Perhaps he clicked the icon by mistake and now just wants to get out without gathering any information? Perhaps even log out and/or shutdown the system? Will you make the user wait for WMI to return unneeded data rather than simply abort the thread? Is WMI special? What if it were just a lengthy database query?
|
|
|
|
|
Well even if I called a abort on a thread will it abort during the call to WMI or wait for it to finish? The whole application is to retrieve services ( and their status ), installed applications with MSI, and other information like the type of drives it has.
So what you are suggesting is to cancel a form close then abort the threads? How do you know when the threads are fully aborted to where it is safe to close the form?
I'm a little new to using threads like this, but creating a new thread (not as background) will run even if the application is closed correct? All I want to do is not make a user wait (or think he/she is waiting) to close a form because WMI is finishing, but WMI doesn't really come with a "cancel" method. Users don't like to wait lol
Edit:
If I'm correct WMI will always end. It will either timeout, throw an error (which I have it just returning the error message by writing it in the eventlog), or return the actual data)
|
|
|
|
|
Use Join or check IsAlive?
Jacob Dixon wrote: Users don't like to wait
Especially if they don't need the thing they don't want to wait for.
Jacob Dixon wrote: cancel a form close then abort the threads
No. And don't make the form depend on threads that way.
|
|
|
|
|
I'm not really sure how to do this without "making the form depend on the threads". I have to use threads to get this information or the GUI will just lock up. Not letting the user close the form because the thread is still working is not feasible.
What you are suggesting is to check if a thread is alive on FormClosing (how else do you know when a user is closing a form), then if it is alive call a Thread.Abort(). I am not sure how threads abort.. so if it is in the middle of the WMI call does it ABORT then or wait until the WMI is finished and then abort?
If I join it with the main thread it will lock up the GUI right?
|
|
|
|
|
Jacob Dixon wrote: check if a thread is alive on FormClosing
No, the form shouldn't know about that thread at all -- it's within the class that handles the WMI calls -- just allow the form to close. The canceling/aborting of the WMI call is separate.
If I understand Dave's suggestion correctly... write a class that
0) Handles WMI requests
1) Holds the retrieved data
2) Raises an event to say that the data is available
In your Main... instantiate the WMI class, and pass a reference to it to the form (perhaps in the constructor).
The form stores the reference and attaches a handler.
When the user requests data, the form passes the request to the WMI class.
The WMI class performs the request on a thread.
When the data is ready it raises the event.
The form then does its thing.
When the form closes, it detatches its handler.
Then, if nothing else is using the WMI instance, that instance gets disposed -- it may have to abort a thread if it was busy at the time.
Something like:
using ( WMI wmi = new WMI() )
{
Application.Run ( new MyForm ( WMI ) ) ;
}
The form shouldn't know anything about what WMI does.
|
|
|
|
|
Jacob Dixon wrote: Well even if I called a abort on a thread will it abort during the call to WMI or wait for it to finish?
That's why I said don't worry about aborting it. The behavior of WMI is undefined if the caller is killed off before the WMI call returns. At least, i couldn't find definitive documentation on what the behavior is anyway.
Jacob Dixon wrote: I'm a little new to using threads like this, but creating a new thread (not as background) will run even if the application is closed correct?
If the thread is not tagged as background, the application will not close. Background threads do not prevent the app from closing.
|
|
|
|
|
I agree with Dave. You should set up a class to do the work for you, and when it is complete, it should fire an event that returns the values it found.
As an example, I have a program that has to extract the column information from an OLAP data cube. This process can take a long time, but I need the information to fill out the different parts of the form. But, sometimes, the user has finished filling out the form before the entire cube was loaded, or they decide to quit. So, on the form close, the first thing I do is to hide the form. As far as the user is concerned, the form is hidden.
Then, I send the call to the class to tell it to abort. The class looks for that abort message periodically as its working, and if it gets it, it will quit loading. Then, in the Form_Close method, I hook the BackgroundWorker.RunWorkerCompleted Event. When that event fires, I know that the process has completed, and I can dispose of the thread and form safely.
In your case, you can't tell it to prematurely stop, but you can let it finish loading in the background, but still hide the form from the user so that they think it is closed.
|
|
|
|
|
Well see I can't abort WMI.
ALL I can do is basically tell my code NOT to write the data to form if it sees the Handle isn't there. Now on the events do you mean something like this:
MAIN THREAD:
public delegate void UserRetrievalDelegate();
public event UserRetrievalDelegate UserRetrievalFinished;
private void frmMain_Load(object sender, EventArgs e)
{
UserRetrievalFinished += new UserRetrievalDelegate(frmMain_UserRetrievalFinished);
}
void frmMain_UserRetrievalFinished()
{
PopulateUsers();
}
USER RETRIEVAL THREAD (Not Main thread):
private void FillUsers()
{
users = new List<User>();
LDAP ldap = Login();
if (ldap != null)
{
PrincipalSearchResult<Principal> usrs = ldap.AllADUsers();
foreach (Principal principal in usrs)
{
User temp = ldap.GetUserInfo(principal.Name, "name");
users.Add(temp);
temp = null;
}
UserRetrievalFinished();
}
}
So the thread fires the event which calls my populateusers method from the main thread?
|
|
|
|
|
Nope.
The way you have it, PopulateUsers is not "from the main thread". It will be executed by the caller, on the caller's thread, as always. You need a delegate and a Control.Invoke to force the method to be called on the main thread; just moving some code from one source location to another cannot solve this.
You may want to read this[^]; you do not really need Control.InvokeRequired here, as you are certain the caller is some other thread.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
