|
Thanks for your review, N a v a n e e t h!
It is clear now.
regards,
George
|
|
|
|
|
For a console app, you could put try/catch around the guts of your main() function.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hi John,
I think in this approach, we can only catch exception from main thread, right?
(Suppose we create new threads from main methods, then we can not catch exception from other threads in main method?)
regards,
George
|
|
|
|
|
If you wanted to go that far you can catch errors in your thread method also...
Are you looking for on error resume next type functionally? If so might be better to use VB.NET as C# doesn't allow for that coding horror
You need to remember the following:
Using exceptions to control programming logic is is the same as having car insurance to repair the damange after rolling off a cliff instead of setting the parking break to prevent it from rolling away.
|
|
|
|
|
Thanks Spacix,
1.
Spacix One wrote: If you wanted to go that far you can catch errors in your thread method also...
So, no means to catch exception from another thread, right?
2.
Spacix One wrote: on error resume next type functionally? If so might be better to use VB.NET as C# doesn't allow for that coding horror
Sorry, I have no experience in VB. Could you say something alternative to describe your ideas please? I do not quite understand, especially what do you mean "on error resume next type functionally".
regards,
George
|
|
|
|
|
George_George wrote: I do not quite understand, especially what do you mean "on error resume next type functionally".
It's a VB syntax used to resume the processing on errors. If on error resume next is provided on the code, errors will be skipped. Keep it in mind, this is for VB/VB.NET and not for C#.
|
|
|
|
|
Thanks for clarification, N a v a n e e t h!
regards,
George
|
|
|
|
|
N a v a n e e t h answered #2
As for number one you can catch them in that thread, example:
System.Threading.Thread mythread = new System.Threading.Thread
(delegate()
{
try
{
throw new Exception("Oh no, my thread crashed!");
}
catch(Exception err)
{
File.WriteAllText(Environment.GetFolderPath(Environment.SpecialFolder.Desktop) + @"\error.log",
DateTime.Now.ToString() + Environment.NewLine + err.ToString() + Environment.NewLine + Environment.NewLine);
}
});
mythread.Start();
|
|
|
|
|
|
Mostly, it's hard to state this is the ONLY case. It matters on who owns the threads and other stuff. It's definitely ONE way
|
|
|
|
|
Could you show me another way to catch exception from another thread please?
regards,
George
|
|
|
|
|
Indeed, I always put a try/catch in the Main.
|
|
|
|
|
But you can never catch exception from other threads, PIEBALDconsult.
regards,
George
|
|
|
|
|
Hello everyone,
I am learning from,
http://msdn2.microsoft.com/en-us/library/2e08f6yc(VS.80).aspx
two simple questions,
1. For every degelate we defined (just a normal C# delegate, no special, and not special designed for asynchronous method call purpose), BeginInvoke and EndInvoke will be defined automatically for every delegate, right? (just looks like for every class we defined, toString, GetHashCode, etc. are defined automatically?)
2. What are the pros and cons compared with the pattern of using EndInvoke to wait for result and the pattern of using WaitHandle to wait for result. To my points, I think they function the same -- block the execution of current thread/method.
thanks in advance,
George
|
|
|
|
|
Umm there are more options than that, but...
If you wish to limit scope to IAsyncResult w/ EndInvoke and WaitHandle.WaitOne
just using EndInvoke allows you to check the IAsyncResult object to see if it finished, if not run other crap until it is then call EndInvoke
the WaitHandle's WaitOne method will block all execution once called until the delegate returns (doesn't allow for state checking to do bust work)
|
|
|
|
|
Thanks Spacix,
1.
"just using EndInvoke allows you to check the IAsyncResult object to see if it finished, if not run other crap until it is then call EndInvoke", no you can not, EndInvoke will be blocked if the aynchronous call is not completed yet.
2.
From this point, I do not see any different effect of using EndInvoke and WaitHandle.
Any comments?
regards,
George
|
|
|
|
|
George_George wrote: BeginInvoke and EndInvoke will be defined automatically for every delegate, right?
Yes.
George_George wrote: just looks like for every class we defined, toString, GetHashCode, etc. are defined automatically?)
Those are inherited from the base class object .
George_George wrote: What are the pros and cons compared with the pattern of using EndInvoke to wait for result and the pattern of using WaitHandle to wait for result. To my points, I think they function the same
Yes, both method blocks execution of current thread. But WaitHandle.WaitOne() allows you to do some processing before EndInvoke() is called. I prefer to use the 4th method explained in that MSDN article. I will pass a call back method reference and call EndInvoke() in that method.
|
|
|
|
|
Must remember the other execution is stuff not within the thread that the waitone was called on or other processes running on the system.
|
|
|
|
|
Thanks Spacix,
Spacix One wrote: Must remember the other execution is stuff not within the thread that the waitone was called on or other processes running on the system.
Could you describe your above points in some other words please? Sorry my English is not very good and I am very interested to learn from your points.
regards,
George
|
|
|
|
|
Thanks N a v a n e e t h,
N a v a n e e t h wrote: But WaitHandle.WaitOne() allows you to do some processing before EndInvoke() is called
I agree all of your points and they are great! Except the above one, I think EndInvoke can achieve the same effect, e.g. you can do something and then invoke EndInvoke.
So, I think the approach of using EndInvoke and the approach of using WaitHandle are the same (at least from functional and effective perspective)?
regards,
George
|
|
|
|
|
George_George wrote: I think EndInvoke can achieve the same effect, e.g. you can do something and then invoke EndInvoke.
It not same fully even though it looks same. When you use WaitOne() , you are allowed to do some extra processing before EndInvoke() is called. That is WaitOne() will wait until the asynchronous method signals it, then the code will come to the next line where you can do further processing and call EndInvoke(). But if you call EndInvoke() directly, it blocks the current thread until it returns the result. Hence you won't be able to do any further processing outside the asynchronous method.
Hope it's clear.
|
|
|
|
|
Thanks N a v a n e e t h,
I want to confirm with you that we can call EndInvoke even if after the asynchronous method completes to retrieve results, right (in this case, EndInvoke will return immediately)?
regards,
George
|
|
|
|
|
George_George wrote: we can call EndInvoke even if after the asynchronous method completes to retrieve results, right
I am sorry, but I am not getting you. Can you rephrase your question ?
George_George wrote: N a v a n e e t h,
There is no space in my name. It's Navaneeth. I added space simply
|
|
|
|
|
Thanks Navaneeth,
Sorry for my bad English.
My question is, if we call EndInvoke after the completion of the asynchronous method, EndInvoke will not be blocked and we will get return result from EndInvoke (or exception) without blocking, right?
regards,
George
|
|
|
|
|
Yes. It will be returned immediately.
|
|
|
|