uncaught exception handlers
-
Derek Bartram wrote:
Does anyone know if a try...catch block affects the performance of the try block code? I know it has a performance hit on hitting the block, but I wonder if it has a continuing effect beyond that.
I once worked on a project where the Project Lead insisted on try catch blocks in every bloody method. 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.
I'm largely language agnostic
After a while they all bug me :doh:
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
-
Thanks Derek, So, "massive improvement" you mean performance improvements? regards, George
Yes. Although perhaps also in terms of code style.
-
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; // 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
-
Yes. Although perhaps also in terms of code style.
Thanks Derek, It is clear now. Sorry for my bad English. :-) regards, George
-
Thanks Derek, It is clear now. Sorry for my bad English. :-) regards, George
No problem. Your english is VERY good, certainly better than my other languages :)
-
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
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;
-
No problem. Your english is VERY good, certainly better than my other languages :)
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
-
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 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 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
Thanks for your review, N a v a n e e t h! It is clear now. regards, George
-
Thanks Spacix, What do you mean "using exceptions to contol logic"? We should never throw any exception when there is some logical errors during runtime? regards, George
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|
-
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|
Thanks for your clarification, Spacix! regards, George