uncaught exception handlers
-
Hello everyone, I am new to how to catch uncaught exception. From some self-learning, I think we should use, event handler for AppDomain.CurrentDomain.UnhandledException other than Application.ThreadException if we are writing console or Windows service, right? Application.ThreadException is for Windows Form application, not console and Windows Service application? thanks in advance, George
-
Hello everyone, I am new to how to catch uncaught exception. From some self-learning, I think we should use, event handler for AppDomain.CurrentDomain.UnhandledException other than Application.ThreadException if we are writing console or Windows service, right? Application.ThreadException is for Windows Form application, not console and Windows Service application? thanks in advance, George
try
{
}
catch (Exception exp)
{
}Maybe, just maybe... ;)
-Spacix All your skynet questions[^] belong to solved
-
Hello everyone, I am new to how to catch uncaught exception. From some self-learning, I think we should use, event handler for AppDomain.CurrentDomain.UnhandledException other than Application.ThreadException if we are writing console or Windows service, right? Application.ThreadException is for Windows Form application, not console and Windows Service application? thanks in advance, George
George_George wrote:
Application.ThreadException is for Windows Form application, not console and Windows Service application?
I don't think that there is a method to do this on console applications. In windows applications, you can hook event handlers to
Application.ThreadExceptionorAppDomain.CurrentDomain.UnhandledException. But these event handlers won't be executed in all cases. If the exception is occurring before the event handler is hooked, it won't be handled. Also exceptions occurring in unmanaged resources won't be handled too.All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions
-
try
{
}
catch (Exception exp)
{
}Maybe, just maybe... ;)
-Spacix All your skynet questions[^] belong to solved
Correct me if i'm wrong, but generally catching things using catch (Exception err) is bad practice? You should try any catch specific exceptions otherwise you get a much greater performance hit I believe. *A point always worth mentioning (particularily to people new to the language); try to avoid using try...catch as much as possible due to the massive performance hit it (hundreds of times slower to process try...catch than simple math functions).
-
Correct me if i'm wrong, but generally catching things using catch (Exception err) is bad practice? You should try any catch specific exceptions otherwise you get a much greater performance hit I believe. *A point always worth mentioning (particularily to people new to the language); try to avoid using try...catch as much as possible due to the massive performance hit it (hundreds of times slower to process try...catch than simple math functions).
No you're not wrong, you should catch what the error is, but if you don't KNOW what is is (thus you got the unhanded exception) you can add a general
catch (Exception err)
{
}which can allow you diagnose it/ silently write a log entry for the problem to be corrected. If you are doing: int i = 3 + 4; there isn't a need for a try-catch but normally with FileIO and other process (that are slower than the try catch block itself) they are fine.... It's hard to judge when/where you need them as you are starting off.
-Spacix All your skynet questions[^] belong to solved
-
No you're not wrong, you should catch what the error is, but if you don't KNOW what is is (thus you got the unhanded exception) you can add a general
catch (Exception err)
{
}which can allow you diagnose it/ silently write a log entry for the problem to be corrected. If you are doing: int i = 3 + 4; there isn't a need for a try-catch but normally with FileIO and other process (that are slower than the try catch block itself) they are fine.... It's hard to judge when/where you need them as you are starting off.
-Spacix All your skynet questions[^] belong to solved
Actually, he is right. You should only do a catch all when performing an operation that you're willing to let fail, or at the top level, to report errors to an end user and write them to a log. The only reason to catch all, is because you're looking to work out why your code is failing, and to log an error.
Christian Graus Please read this if you don't understand the answer I've given you "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
No you're not wrong, you should catch what the error is, but if you don't KNOW what is is (thus you got the unhanded exception) you can add a general
catch (Exception err)
{
}which can allow you diagnose it/ silently write a log entry for the problem to be corrected. If you are doing: int i = 3 + 4; there isn't a need for a try-catch but normally with FileIO and other process (that are slower than the try catch block itself) they are fine.... It's hard to judge when/where you need them as you are starting off.
-Spacix All your skynet questions[^] belong to solved
Spacix One wrote:
which can allow you diagnose it
And if nothing else, I guess that's the answer to the orriginal question; set a break point in the catch block and Visual Studio will tell you the type of the exception (and hence you can modify the code to catch exactly that). 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.
-
George_George wrote:
Application.ThreadException is for Windows Form application, not console and Windows Service application?
I don't think that there is a method to do this on console applications. In windows applications, you can hook event handlers to
Application.ThreadExceptionorAppDomain.CurrentDomain.UnhandledException. But these event handlers won't be executed in all cases. If the exception is occurring before the event handler is hooked, it won't be handled. Also exceptions occurring in unmanaged resources won't be handled too.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, What do you mean "windows applications"? I have checked again in VS 2008, there is not a project type names "windows applications". Do you mean Windows Forms application? regards, George
-
try
{
}
catch (Exception exp)
{
}Maybe, just maybe... ;)
-Spacix All your skynet questions[^] belong to solved
Hi Spacix, I doubt whether your approach could achieve the same effect as using Application.ThreadException or AppDomain.CurrentDomain.UnhandledException (suppose there are multple threads)? Any comments? regards, George
-
Correct me if i'm wrong, but generally catching things using catch (Exception err) is bad practice? You should try any catch specific exceptions otherwise you get a much greater performance hit I believe. *A point always worth mentioning (particularily to people new to the language); try to avoid using try...catch as much as possible due to the massive performance hit it (hundreds of times slower to process try...catch than simple math functions).
Thanks Derek, 1.
Derek Bartram wrote:
to avoid using try...catch as much as possible due to the massive performance hit it
Do you mean catching all exception will degrade performance or you mean generally exception handling approach will degrade performance? 2. Do you have any documents to support your points? :-) regards, George
-
No you're not wrong, you should catch what the error is, but if you don't KNOW what is is (thus you got the unhanded exception) you can add a general
catch (Exception err)
{
}which can allow you diagnose it/ silently write a log entry for the problem to be corrected. If you are doing: int i = 3 + 4; there isn't a need for a try-catch but normally with FileIO and other process (that are slower than the try catch block itself) they are fine.... It's hard to judge when/where you need them as you are starting off.
-Spacix All your skynet questions[^] belong to solved
Thanks Spacix, I think when you get exception, and uncaught it, your program will terminate and you will get information from console, for example. In this way, you can know what exception happens. So, no need to catch all exceptions, right? regards, George
-
Actually, he is right. You should only do a catch all when performing an operation that you're willing to let fail, or at the top level, to report errors to an end user and write them to a log. The only reason to catch all, is because you're looking to work out why your code is failing, and to log an error.
Christian Graus Please read this if you don't understand the answer I've given you "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
Thanks Christian, I agree with your points. Any ideas to my original question? About using using Application.ThreadException or AppDomain.CurrentDomain.UnhandledException in console/Windows service application? regards, George
-
Spacix One wrote:
which can allow you diagnose it
And if nothing else, I guess that's the answer to the orriginal question; set a break point in the catch block and Visual Studio will tell you the type of the exception (and hence you can modify the code to catch exactly that). 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.
Thanks Derek, I agree with your points. Any ideas to my original question? About using using Application.ThreadException or AppDomain.CurrentDomain.UnhandledException in console/Windows service application? regards, George
-
Thanks Derek, 1.
Derek Bartram wrote:
to avoid using try...catch as much as possible due to the massive performance hit it
Do you mean catching all exception will degrade performance or you mean generally exception handling approach will degrade performance? 2. Do you have any documents to support your points? :-) regards, George
I've just done some googling on the subject (and confirmed via a lecturer from Uni).... 1) There is a performance hit running code inside a try...catch block but it's negligable 2) There is a BIG performance hit when an exception occurs So, 3) Use try...catch for only catching untestable errors and not controlling programming flow. http://www.javaworld.com/javaworld/javaqa/2001-07/04-qa-0727-try.html[^] http://aspadvice.com/blogs/name/archive/2008/01/18/Try-Catch-Performance-in-CSharp_3A00_-A-Simple-Test-Response.aspx[^]
-
Thanks Derek, I agree with your points. Any ideas to my original question? About using using Application.ThreadException or AppDomain.CurrentDomain.UnhandledException in console/Windows service application? regards, George
Yes.... run the code with catch (Exception err) and output err.GetType() somehow (Console.WriteLine will do). You'll then know the type of the exception raised so you can go back and modify catch (Exception err) to the specific type.
-
I've just done some googling on the subject (and confirmed via a lecturer from Uni).... 1) There is a performance hit running code inside a try...catch block but it's negligable 2) There is a BIG performance hit when an exception occurs So, 3) Use try...catch for only catching untestable errors and not controlling programming flow. http://www.javaworld.com/javaworld/javaqa/2001-07/04-qa-0727-try.html[^] http://aspadvice.com/blogs/name/archive/2008/01/18/Try-Catch-Performance-in-CSharp_3A00_-A-Simple-Test-Response.aspx[^]
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
-
Yes.... run the code with catch (Exception err) and output err.GetType() somehow (Console.WriteLine will do). You'll then know the type of the exception raised so you can go back and modify catch (Exception err) to the specific type.
Thanks Derek, I agree with your exception handling approach. Any answers or comments to my original question? :-) regards, George
-
Hello everyone, I am new to how to catch uncaught exception. From some self-learning, I think we should use, event handler for AppDomain.CurrentDomain.UnhandledException other than Application.ThreadException if we are writing console or Windows service, right? Application.ThreadException is for Windows Form application, not console and Windows Service application? thanks in advance, George
For a console app, you could put try/catch around the guts of your main() function.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
For a console app, you could put try/catch around the guts of your main() function.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Hi John, I think in this approach, we can only catch exception from main thread, right? (Suppose we create new threads from main methods, then we can not catch exception from other threads in main method?) regards, George
-
Correct me if i'm wrong, but generally catching things using catch (Exception err) is bad practice? You should try any catch specific exceptions otherwise you get a much greater performance hit I believe. *A point always worth mentioning (particularily to people new to the language); try to avoid using try...catch as much as possible due to the massive performance hit it (hundreds of times slower to process try...catch than simple math functions).
