uncaught exception handlers

[George_George]

Thanks for your clarification, Derek! regards, George

[George_George]

Thanks Derek, So, "massive improvement" you mean performance improvements? regards, George

[Derek Bartram]

MidwestLimey wrote:

I once worked on a project where the Project Lead insisted on try catch blocks in every bloody method.

That sounds a little overkill, however generally I do use try...catch blocks in all my gui event handlers so that application is a little more useful when something does go wrong.

MidwestLimey wrote:

I did some performance testing and could determine definitive costs with the setup and teardown of the block, but was unable to measure any discernable difference to the code internally. However the code was entirely managed, perhaps wrapping unmanaged code has other implications.

Thank you for that, personally that is of great interest. I'm actually in the middle of writing a series of articles on language performance so hopefully i'll be able to give further insite on this. Many thanks, Derek Bartram

[Derek Bartram]

Yes. Although perhaps also in terms of code style.

[N a v a n e e t h]

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; // 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

}

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.

All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions

[George_George]

Thanks Derek, It is clear now. Sorry for my bad English. :-) regards, George

[Derek Bartram]

No problem. Your english is VERY good, certainly better than my other languages :)

[George_George]

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

/*
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;

[George_George]

Thanks for your patience to help me, Derek! :-) I think one of the most important things for developer is to be patience to learn new things. regards, George

[N a v a n e e t h]

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.

All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions

[George_George]

Thanks for your review, N a v a n e e t h! It is clear now. regards, George

[Spacix One]

Like in my second code block, if you throw in your method and you catch it to only return something less complex, or change your structure. Hmm better example: (This is an intentional BAD code example!)

    static FileStream openFile(string filePath)
    {
        FileStream fs;
        try
        {
            fs = File.OpenRead(filePath);
        }
        catch (FileNotFoundException err)
        {
            File.Create(filePath);
            fs = File.OpenRead(filePath);
        }
        return fs;
    }

That is bad because you could just used File.Exist() to check for the file before opening it, and make it before trying to call OpenRead() on it. I know this is pointless but still an example of a NEVER do...

---

-Spacix All your skynet questions[^] belong to solved

---

I dislike the black-and-white voting system on questions/answers. X|

---

[George_George]

Thanks for your clarification, Spacix! regards, George