C#

George_George wrote:

So, asynchronous function call is the only case when we can catch exception from another thread?

Exception raisedException = null; // This is accessible in the whole class
void BeginRead()
{
   try{
      //Do some asynchronous process
   }
   cath(Exception ex){
      raisedException = ex;
   }
}
void EndRead()
{
    // Do something to stop asynchronous processing. You will call WaitHandle.WaitOne() here.
    if(raisedException != null) throw raisedException; //We are throwing the exception occured

    // No exceptions. So return the result
}

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.

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");
/*
            AppDomain.CurrentDomain.ProcessExit += new EventHandler (Test.Handler1);
            AppDomain.CurrentDomain.UnhandledException +=new UnhandledExceptionEventHandler(Test.Handler3);
 */
      /*      
            Thread aThread
                = new Thread(new ThreadStart(Method1));
            aThread.Start();
        */

            // ThreadPool.QueueUserWorkItem(new WaitCallback(Test.Method2));

            
            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;

        } // main
    }
}

George_George wrote:

My point is we should handle it in main thread. Here is my code to prove. Any comments?

Spacix One wrote:

If you wanted to go that far you can catch errors in your thread method also...

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

George_George wrote:

I do not quite understand, especially what do you mean "on error resume next type functionally".

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();

George_George wrote:

BeginInvoke and EndInvoke will be defined automatically for every delegate, right?

George_George wrote:

just looks like for every class we defined, toString, GetHashCode, etc. are defined automatically?)

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

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.

N a v a n e e t h wrote:

But WaitHandle.WaitOne() allows you to do some processing before EndInvoke() is called

George_George wrote:

I think EndInvoke can achieve the same effect, e.g. you can do something and then invoke EndInvoke.