|
You're welcome, but please in the future spend a good 10-20 minutes googling your query and reading the results. If that doesn't work, post to the forums.
Till the next time 
"Every time Lotus Notes starts up, somewhere a puppy, a kitten, a lamb, and a baby seal are killed. Lotus Notes is a conspiracy by the forces of Satan to drive us over the brink into madness. The CRC-32 for each file in the installation includes the numbers 666." Gary Wheeler
"You're an idiot." John Simmons, THE Outlaw programmer
"I realised that all of my best anecdotes started with "So there we were, pissed". Pete O'Hanlon
|
|
|
|
|
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... 
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Yes. A breakpoint on the err.GetType() line will give you further information as well however.
|
|
|
|
|
Thanks for your clarification, Derek!
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 
|
|
|
|
|
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
|
|
|
|
|
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
{
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 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? 
I'm largely language agnostic
After a while they all bug me
|
|
|
|
|
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. 
|
|
|
|
|
Thanks for your clarification, Spacix!
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
