uncaught exception handlers
-
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 nextis provided on the code, errors will be skipped. Keep it in mind, this is for VB/VB.NET and not for C#.All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions
-
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
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();
-Spacix All your skynet questions[^] belong to solved
-
George_George wrote:
and I have tried even ProcessExit
ProcessExist is not needed here
George_George wrote:
After the handler for UnhandledException is executed, process is always terminated?
mm, look like you are still not clear. I will try to explain once more.
AppDomain.UnhandledExceptionis not an exception handler likecatch. It's an event which will be fired before program exits due to uncaught error. After handler is executed, process will be terminated. This is a new behavior from .NET 2.0 onwards. In handler you can do necessary steps to log the error. You can't prevent application ending. In that handler you can show friendly messages to user and inform him that we are closing. Considering all these points in mind, your demo code is working as expected. Handler is getting executed and application is closing. You need to change thehandler3()method like this.private static void Handler3(object sender, UnhandledExceptionEventArgs e)
{
Exception exceptionOccured = e.ExceptionObject as Exception;
string errorMessage = exceptionOccured.Message;
Console.WriteLine("I am here");
}. In this you can see how exception occurred is retrieved from the event argument. You can log the exception message and application will be exited gracefully. .NET 1.1 behavior can be taken back by setting some flag value in application.config file. See this[^]. But I don't recommend that, as I don't know the pros/cons of that. Hope it's 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, Cool! I have made further tests that, there is one exception case. When exception is from thread pool thread -- 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. So, here is a case when there is unhandled exception in another thread, we can still catch it and not make process terminated. :-) Any comments? 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 nextis provided on the code, errors will be skipped. Keep it in mind, this is for VB/VB.NET and not for C#.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 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();
-Spacix All your skynet questions[^] belong to solved
Yes, Spacix! I agree with your code. I think the only case which we can catch exception other threads and prevent application process from termination is, http://www.codeproject.com/script/Forums/View.aspx?fid=1649&msg=2529071[^] Agree? Any comments? :-) regards, George
-
What do you mean "unable to measure any discernable difference to the code internally"? regards, George
I couldn't find a time difference for the execution of the same code block when wrapped in a try catch as opposed to not.
I'm largely language agnostic
After a while they all bug me :doh:
-
I couldn't find a time difference for the execution of the same code block when wrapped in a try catch as opposed to not.
I'm largely language agnostic
After a while they all bug me :doh:
Thanks MidwestLimey, So you mean the performance impact of exception handling is minor? regards, George
-
Yes, Spacix! I agree with your code. I think the only case which we can catch exception other threads and prevent application process from termination is, http://www.codeproject.com/script/Forums/View.aspx?fid=1649&msg=2529071[^] Agree? Any comments? :-) regards, George
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 :)
-Spacix All your skynet questions[^] belong to solved
-
Thanks MidwestLimey, So you mean the performance impact of exception handling is minor? regards, George
I think he means the use of the
try
{
}
catch...WITHOUT an Exception being thrown has little to no effect on code. The problem is when Exceptions do occur it slows everything down. Though I think that is better than the WHOLE app crashing to a grinding halt and a .NET error message dialog showing then the Microsoft error reporting tool (if enabled) poping up. Though this has been stated many times in this thread, using exceptions to contol logic is VERY VERY bad code:
public static bool someMethod()
{
try
{
//code process
if(somthing wrong)
{
throw new Exception("Error!!");
}
}
catch(Exception err)
{
return false;
}
}There are only a few exceptions(pun intended) to this rule and anytime I've seen something like the code as above wasn't needed...
-Spacix All your skynet questions[^] belong to solved
-
Thanks MidwestLimey, So you mean the performance impact of exception handling is minor? regards, George
I mean the code within the block doesn't magically slow down, however establishing the try catch block and then tearing it down does use some cycles.
I'm largely language agnostic
After a while they all bug me :doh:
-
I think he means the use of the
try
{
}
catch...WITHOUT an Exception being thrown has little to no effect on code. The problem is when Exceptions do occur it slows everything down. Though I think that is better than the WHOLE app crashing to a grinding halt and a .NET error message dialog showing then the Microsoft error reporting tool (if enabled) poping up. Though this has been stated many times in this thread, using exceptions to contol logic is VERY VERY bad code:
public static bool someMethod()
{
try
{
//code process
if(somthing wrong)
{
throw new Exception("Error!!");
}
}
catch(Exception err)
{
return false;
}
}There are only a few exceptions(pun intended) to this rule and anytime I've seen something like the code as above wasn't needed...
-Spacix All your skynet questions[^] belong to solved
Spacix One wrote:
The problem is when Exceptions do occur it slows everything down. Though I think that is better than the WHOLE app crashing to a grinding halt and a .NET error message dialog showing then the Microsoft error reporting tool (if enabled) poping up.
You mean you don't think users like that? :D
I'm largely language agnostic
After a while they all bug me :doh:
-
Thanks N a v a n e e t h, Cool! I have made further tests that, there is one exception case. When exception is from thread pool thread -- 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. So, here is a case when there is unhandled exception in another thread, we can still catch it and not make process terminated. :-) Any comments? regards, George
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.
All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions
-
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 :)
-Spacix All your skynet questions[^] belong to solved
Could you show me another way to catch exception from another thread please? :-) regards, George
-
I think he means the use of the
try
{
}
catch...WITHOUT an Exception being thrown has little to no effect on code. The problem is when Exceptions do occur it slows everything down. Though I think that is better than the WHOLE app crashing to a grinding halt and a .NET error message dialog showing then the Microsoft error reporting tool (if enabled) poping up. Though this has been stated many times in this thread, using exceptions to contol logic is VERY VERY bad code:
public static bool someMethod()
{
try
{
//code process
if(somthing wrong)
{
throw new Exception("Error!!");
}
}
catch(Exception err)
{
return false;
}
}There are only a few exceptions(pun intended) to this rule and anytime I've seen something like the code as above wasn't needed...
-Spacix All your skynet questions[^] belong to solved
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
-
I mean the code within the block doesn't magically slow down, however establishing the try catch block and then tearing it down does use some cycles.
I'm largely language agnostic
After a while they all bug me :doh:
Thanks for clarifying this, MidwestLimey! regards, George
-
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.
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, So, asynchronous function call is the only case when we can catch exception from another thread? regards, George
-
Thanks Derek, Cool!! Your 1st link is Java... :-) I am interested in your 2nd link. But confused what means "catching untestable errors" and "not controlling programming flow"? Could you show some samples please? regards, George
George_George wrote:
But confused what means "catching untestable errors"
//writer is a stream writer to a file.. try { writer.Write("Hello"); } catch (Exception err) { //handle error } In this case you couldn't test for every possible error as some are far out the scope of plausible; e.g. can't access the file as it was on a removable drive that was just unplugged.
George_George wrote:
"not controlling programming flow"?
//slider is a silder whos value is 0 to 100 double y = 100.0 / slider.Value then try { double y = 100.0 / slider.Value } catch (Exception) { //handler exception } is a bad way to write this code (remembing slider.Value could be 0 causing divide by 0 exception), a better way would be.... if (slider.Value != 0) { double y = 100.0 / slider.Value } else { handle error }
-
Thanks Derek, I agree with your exception handling approach. Any answers or comments to my original question? :-) regards, George
See above. I don't know the answer, but use the proceedure above will tell you how to find out.
-
George_George wrote:
But confused what means "catching untestable errors"
//writer is a stream writer to a file.. try { writer.Write("Hello"); } catch (Exception err) { //handle error } In this case you couldn't test for every possible error as some are far out the scope of plausible; e.g. can't access the file as it was on a removable drive that was just unplugged.
George_George wrote:
"not controlling programming flow"?
//slider is a silder whos value is 0 to 100 double y = 100.0 / slider.Value then try { double y = 100.0 / slider.Value } catch (Exception) { //handler exception } is a bad way to write this code (remembing slider.Value could be 0 causing divide by 0 exception), a better way would be.... if (slider.Value != 0) { double y = 100.0 / slider.Value } else { handle error }
Thanks Derek, I agree with your sample one. But for the sample two, I can not see any advantage for the 1st sample. Because for the 2nd you preferred sample, when we write code for "handle error" in else bracket, we usually throw exception. So, both samples have the same effect of exception thrown when we met with divide by zero issues. So, what do you think are the advantages?
try
{
double y = 100.0 / slider.Value
}
catch (Exception)
{
//handler exception
}is a bad way to write this code (remembing slider.Value could be 0 causing divide by 0 exception), a better way would be....
if (slider.Value != 0)
{
double y = 100.0 / slider.Value
}
else
{
handle error
}regards, George
-
See above. I don't know the answer, but use the proceedure above will tell you how to find out.
Thanks Derek, "the proceedure above" you mean "catch (Exception err) and output err.GetType()"? regards, George