Re: uncaught exception handlers - C# Discussion Boards

Re: uncaught exception handlers

George_George29-Apr-08 19:59

George_George

29-Apr-08 19:59

Thanks for clarifying this, MidwestLimey!

regards,
George

Re: uncaught exception handlers

Derek Bartram30-Apr-08 5:23

Derek Bartram

30-Apr-08 5:23

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

Re: uncaught exception handlers

George_George26-Apr-08 21:23

George_George

26-Apr-08 21:23

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

Re: uncaught exception handlers

George_George26-Apr-08 21:14

George_George

26-Apr-08 21:14

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? Smile | :)

regards,
George

Re: uncaught exception handlers

Derek Bartram27-Apr-08 0:12

Derek Bartram

27-Apr-08 0:12

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[^]

Re: uncaught exception handlers

George_George27-Apr-08 2:08

George_George

27-Apr-08 2:08

Thanks Derek,

Cool!!

Your 1st link is Java... Smile | :)

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

Re: uncaught exception handlers

Derek Bartram30-Apr-08 1:49

Derek Bartram

30-Apr-08 1:49

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
}

Re: uncaught exception handlers

George_George30-Apr-08 3:58

George_George

30-Apr-08 3:58

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

Re: uncaught exception handlers

Derek Bartram30-Apr-08 4:54

Derek Bartram

30-Apr-08 4:54

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.

Re: uncaught exception handlers

George_George30-Apr-08 5:08

George_George

30-Apr-08 5:08

Thanks for your clarification, Derek!

It is clear now. Smile | :)

regards,
George

Re: uncaught exception handlers

PIEBALDconsult27-Apr-08 4:37

PIEBALDconsult

27-Apr-08 4:37

Derek Bartram wrote:
massive performance hit

Perhaps you haven't read this[^] yet.

Re: uncaught exception handlers

Derek Bartram27-Apr-08 6:56

Derek Bartram

27-Apr-08 6:56

Thanks for the link, an interesting article. I probably didn't specify 'massive' which didn't help; I meant relative to performing an if test to prevent the exception.

Re: uncaught exception handlers

George_George27-Apr-08 20:17

George_George

27-Apr-08 20:17

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

Re: uncaught exception handlers

Derek Bartram30-Apr-08 5:08

Derek Bartram

30-Apr-08 5:08

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).

Re: uncaught exception handlers

George_George30-Apr-08 5:11

George_George

30-Apr-08 5:11

Thanks Derek,

So, "massive improvement" you mean performance improvements?

regards,
George

Re: uncaught exception handlers

Derek Bartram30-Apr-08 5:48

Derek Bartram

30-Apr-08 5:48

Yes. Although perhaps also in terms of code style.

Re: uncaught exception handlers

George_George1-May-08 2:13

George_George

1-May-08 2:13

Thanks Derek,

It is clear now. Sorry for my bad English. Smile | :)

regards,
George

Re: uncaught exception handlers

Derek Bartram1-May-08 2:20

Derek Bartram

1-May-08 2:20

No problem. Your english is VERY good, certainly better than my other languages Smile | :)

Re: uncaught exception handlers

George_George1-May-08 2:45

George_George

1-May-08 2:45

Thanks for your patience to help me, Derek! Smile | :)

I think one of the most important things for developer is to be patience to learn new things.

regards,
George

Re: uncaught exception handlers

George_George27-Apr-08 19:56

George_George

27-Apr-08 19:56

Thanks PIEBALDconsult,

Good reference. Smile | :)

regards,
George

Re: uncaught exception handlers

George_George26-Apr-08 21:06

George_George

26-Apr-08 21:06

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

Re: uncaught exception handlers

N a v a n e e t h26-Apr-08 6:15

N a v a n e e t h

26-Apr-08 6:15

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.ThreadException or AppDomain.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

Re: uncaught exception handlers

George_George26-Apr-08 21:04

George_George

26-Apr-08 21:04

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

Re: uncaught exception handlers

N a v a n e e t h27-Apr-08 19:49

N a v a n e e t h

27-Apr-08 19:49

George_George wrote:
Windows Forms application?

Yes. Also you can wrap the main() method in try catch blocks. So it can handle all exceptions.

All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia

How to use google | Ask smart questions

Re: uncaught exception handlers

George_George27-Apr-08 19:55

George_George

27-Apr-08 19:55

No, N a v a n e e t h. Not catch all exceptions, you can not catch exception from other threads? Right?

regards,
George

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.