|
George_George wrote: but in the situation of executing asynchronous method call, we can catch the exception (even if unhandled in the thread pool worker thread) in EndInvoke in main thread.
This how asynchronous methods works. It will handle exception safely and throws when end method is called.
George_George wrote: when there is unhandled exception in another thread, we can still catch it and not make process terminated.
You are always allowed to catch exceptions in the same thread. Cross-thread exception handling is only not possible. In this case also you are handling exceptions in the same thread, so there won't be any issues. Asynchronous method runs on a thread pool thread and handles exception inside that method and keep it until end is called. When end is called, it will check exception is null, if not null it will be thrown.
|
|
|
|
|
Thanks N a v a n e e t h,
So, asynchronous function call is the only case when we can catch exception from another thread?
regards,
George
|
|
|
|
|
George_George wrote: So, asynchronous function call is the only case when we can catch exception from another thread?
George, we are not able to catch exceptions happening on another thread. In this case also it's not happening. We are catching exception in the asynchronous method it self and keeping it for future use. When end method is called, this exception will be thrown out. Have a look at the following code
Exception raisedException = null;
void BeginRead()
{
try{
}
cath(Exception ex){
raisedException = ex;
}
}
void EndRead()
{
if(raisedException != null) throw raisedException;
} In the above code, we have handled the exception and threw it when end is called. Note we handled the exception in the same thread where asynchronous method is executing, not in the main thread.
Hope things are clear now.
|
|
|
|
|
Thanks N a v a n e e t h,
I agree with all of your points, except this one,
N a v a n e e t h wrote: Note we handled the exception in the same thread where asynchronous method is executing, not in the main thread.
My point is we should handle it in main thread. Here is my code to prove. Any comments?
(sorry the code is a little messy, I used it to test for multi-purpose in this discussion.)
using System;
using System.Threading;
namespace DelegateThread
{
class Test
{
private static void Method2 (object input)
{
Console.WriteLine("Method1 is throwing exception");
throw new ApplicationException("**** oops ****");
}
private static void Method1()
{
Console.WriteLine("Method1 is throwing exception");
throw new ApplicationException("**** oops ****");
}
private static void Handler1 (object sender, EventArgs e)
{
Console.WriteLine ("I am here");
}
private static void Handler3(object sender, EventArgs e)
{
Console.WriteLine("I am here");
}
delegate void Method1Delegate();
static void Main(string[] args)
{
Console.WriteLine("We first use a thread");
Console.WriteLine("We will use a Delegate now");
Method1Delegate dlg = new Method1Delegate(Method1);
IAsyncResult handle = dlg.BeginInvoke(null, null);
Thread.Sleep(1000);
Console.WriteLine("Was the exception reported so far?");
try
{
Console.WriteLine("Let's call EndInvoke");
dlg.EndInvoke(handle);
}
catch (Exception ex)
{
Console.WriteLine("Exception: {0}", ex.Message);
}
Thread.Sleep(5000);
Console.WriteLine("Survived exception");
return;
}
}
}
regards,
George
|
|
|
|
|
George_George wrote: My point is we should handle it in main thread. Here is my code to prove. Any comments?
Your code is working perfectly. I guess you tried it by running the application in debug mode - Right ? When application runs on debug mode, VS editor will break when exception occurs and points to the suspected line. You should try running this without in debug mode (Ctrl + F5). You can see it executes correctly. Exception will be caught when EndInvoke() get called.
|
|
|
|
|
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
|
|
|
|