views:

345

answers:

8

Hi!

Basically, the question is: Do the Exceptions in C# affect the performance a lot? Is it better to avoid Exceptions rethrow? If i generate an exception in my code, does it affect a performance?

Sorry for the sillines of the question itself

+9  A: 

If you're worried about exception performance, you're using them wrong.

But yes, exceptions do affect performance.

JaredPar
i'm not worried. i think you should reconsider what you're saying.
ifesdjeen
@opetrov: He's right. You should throw exceptions when something goes wrong, and not to control the flow of the program. For any performance-intensive operations, you should check your input, and make sure exceptions are not going to be thrown at all. Exceptions should be exceptional.
Will Eddins
@opetrov, @Guard summed up the point I was trying to make very well.
JaredPar
+3  A: 

Raising an exception is an expensive operation in C# (compared to other operations in C#) but not enough that I would avoid doing it.

I agree with Jared, if your application is significantly slower because of raising and throwing exceptions, I would take a look at your overall strategy. Something can probably be refactored to make exception handling more efficient rather than dismissing the concept of raising exceptions in code.

Kevin
A: 

This is not silly just I've seen it somewhere else also on SO.

The exceptions occur well, when things are really exceptional. Most of the time you re-throw the exception (may after logging) when there are not many chances of recovering from it. So it should not bother you for normal course of execution of program.

TheVillageIdiot
A: 

Exceptions as its name implies are intended to be exceptional. Hence you can't expect them to have been an important target for optimisation. More often then not they don't perform well since they have other priorites such as gathering detailed info about what went wrong.

AnthonyWJones
A: 

Exceptions in .NET do affect performance. This is the reason why they should be used only in exceptional cases.

Darin Dimitrov
+2  A: 

running code through a try/catch statement does not affect performance at all. The only performance hit comes if an exception is thrown ... because then the runtime has to unwind the stack and gather other information in order to populate the exception object.

Joel Martinez
+3  A: 

What most other folks said, plus: Don't use exceptions as part of the programming flow. In other words, don't throw an exception for something like, account.withdrawalAmount > account.balance. That is a business case.

The other biggie to look out for regarding performance is swallowing exceptions. It's a slippery slope, and once you start allowing your app to swallow exceptions, you start doing it everywhere. Now you may be allowing your app to throw exceptions that you don't know about because you are swallowing them, your performance suffers and you don't know why.

jlembke
A good exception for your trivial case would be account.withDrawalAmount > machine.CashOnHand IMO.
Chris Marisic
@Chris, no, that's still not an exceptional case ... it's actually an expected case. There's a very real possibility that, through no technical failure, the machine may run out of money. Thus, it's a business case.
Joel Martinez
I would agree with Joel on that. Unexpected might possibly be a loss of connectivity or something like that. But part of an ATM's nature is that it holds limited funds that could run out.
jlembke
IMO I'd still handle that one as an exception case because it's primarily not expected to happen and I'd rather handle it that "OutOfMoneyException" shut the machine off / lockout access entirely to the machine etc rather than have that as part of the normal branching logic flow.On top of that, I normally would have some type of global exception policy happening that the exception would trigger some type of alert that the machine needs maintence etc.
Chris Marisic
I would say it is a fairly safe assumption anytime an event occurs that can never be reconciled by an user's actions and needs some type of admin or super level access to fix should be an exception not a business case.Machine lockout vs account lockout are very different in extremes of what happens I wouldn't want the logic for both being directly parallel to each other.
Chris Marisic
+1  A: 

Microsoft's Design Guidelines for Developing Class Libraries is a very valuable resource. Here is a relevant article:

Exceptions and Performance

I would also recommend the Framework Design Guidelines book from Microsoft Press. It has a lot of the information from the Design Guidelines link, but it is annotated by people with MS, and Anders Hejlsberg, himself. It gives a lot of insight into the "why" and "how" of the way things are.

joseph.ferris