0

Is there an extra cost involved when I throw the exception again from a catch block?

I use it to log the exceptions and was wondering about performance cost.

try 
{
    ..
}
catch(Exception e)
{
    ...log exception...
    throw;
}
finally
{
    ...
}
Jay Chheda
  • 1
  • 1
  • 1
    If you have to wonder about how much performance your exceptions cost, you're probably doing it wrong. A sane application is not bottlenecked by exception handling. Besides, there's a clear semantic difference in rethrowing vs. not rethrowing -- it's not like you can just leave it out to speed things up. What you should be concerned about is not logging the same exception 10 times in endless `catch`/`log`/`throw` hierarchies -- this anti-pattern will drive you insane when you have to read the logging. – Jeroen Mostert Mar 30 '18 at 15:08
  • 1
    Why is this a concern to begin with? If your code throws/rethrows so, so many exceptions that rethrowing would be a performance concern, then your code is completely and positively bonkers. No sane code should ever throw so many exceptions that performance of rethrowing should ever become a concern. –  Mar 30 '18 at 15:09
  • The whole idea of logging, then throwing on is not a idea to begin with. I have two articles on proper Exception handling I link a lot that should get you on the right path: http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx | http://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET I agree with the otehrs that this should not be a concern. Exceptions should not be part of the normal operation so their impact should be irrelevant. – Christopher Mar 30 '18 at 15:11
  • 1
    The cost comes when the error occurs. Not when the exception is caught or rethrown. Exceptions are like fuses. You **really** don't care how "expensive" they are, you want them to blow when there's a short circuit, no matter what – Panagiotis Kanavos Mar 30 '18 at 15:12
  • It's not a concern at the moment. Asked for knowledge purpose. I read pages on the cost of exceptions but none of them talked about rethrowing. – Jay Chheda Mar 30 '18 at 15:16
  • As the word implies, rethrowing an exception is just throwing the exception again. It's slightly less expensive than throwing a new exception (since no new object has to be allocated), but again, if you would ever notice this, it's only because you're not doing enough to prevent exceptions in the first place. It's not something you worry about in practice. If for some reason you were still morbidly curious, there's always [BenchmarkDotNet](http://benchmarkdotnet.org/) to measure it. – Jeroen Mostert Mar 30 '18 at 15:19
  • @Christopher Thanks for the links! Will go through them. – Jay Chheda Mar 30 '18 at 15:29
  • @PanagiotisKanavos thanks for the explanation! that helps a lot. – Jay Chheda Mar 30 '18 at 15:29
  • I think it's a reasonable question. Exceptions should be exceptional and it's better to catch and return a handled error instead of letting it short circuit and bubble the exception all the way out. But sometimes it's some other framework that's blocking you from doing that, forcing you to rethrow (i.e. there's no return method). Like Polly. You can't put a timeout fallback on top and a catch all in the middle or else the timeout will never get hit. And the other way around forces a rethrow depending on the return type. I was wondering the same thing about rethrow cost because of this. – Sinaesthetic Nov 26 '21 at 23:47

0 Answers0