uncaught exception handlers
-
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
-
Thanks Derek, "the proceedure above" you mean "catch (Exception err) and output err.GetType()"? regards, George
Yes. A breakpoint on the err.GetType() line will give you further information as well however.
-
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
The point is sample two doesn't throw an exception but rather just run a different section of code. An if statement inherinatly has less overhead than that of a try...catch statement. Certainly both will perform exactly the same function however the second will run more efficiently and quicker.
-
The point is sample two doesn't throw an exception but rather just run a different section of code. An if statement inherinatly has less overhead than that of a try...catch statement. Certainly both will perform exactly the same function however the second will run more efficiently and quicker.
Thanks for your clarification, Derek! It is clear now. :-) regards, George
-
Thanks Derek, What do you mean "didn't specify 'massive' which didn't help" and "relative to performing an if test to prevent the exception"? Could you show more description or some pseudo code about your approach please? regards, George
Firstly, from above //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 }
George_George wrote:
What do you mean "didn't specify 'massive' which didn't help"
It's all very well saying massive improvement or whatever, but if you don't give some quantative value or referance, massive has no meaning (it could save 0.1ms which in terms of clock cycle is alot, but probably less significant to compared to a complex if statement).
-
Yes. A breakpoint on the err.GetType() line will give you further information as well however.
Thanks for your clarification, Derek! regards, George
-
Firstly, from above //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 }
George_George wrote:
What do you mean "didn't specify 'massive' which didn't help"
It's all very well saying massive improvement or whatever, but if you don't give some quantative value or referance, massive has no meaning (it could save 0.1ms which in terms of clock cycle is alot, but probably less significant to compared to a complex if statement).
Thanks Derek, So, "massive improvement" you mean performance improvements? regards, George
-
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 :)