Thread: About try and catch performance.

Let me sum up everything you need to know about try, catch and throw..... don't use them.

Whatever.

Exceptions have their place. Normally when you are throwing an exception it isn't at a time when performance matters. No one brags about how fast or optimized their error handling system is and if they did I would consider them an idiot. Who cares? Exceptions normally cause the entire system to come down anyways and if on the odd chance you can recover and continue you probably won't be doing anything performance oriented anyways. Now if it is real time software or running 24/7/365 for critical tasks then obviously you must recover from an exception, however, not throwing the exception will most likely bring the system crashing down. In the end I'll take the hit for the stability it offers. I see nothing wrong with the try/catch mechanism as long as it is used correctly. Of course it can be abused but that does not mean it is meaningless or has no place in the language. Beware of people who say don't ever use this or that b/c of this or that. I find those types of programmers are both annoying and clueless. The language and it's various elements and mechanisms are there to be used for various situations.....so use them. No one language mechanism is an end all be all of what you should and should not do.

Originally Posted by C_ntua

So basically we are saying that with the modern method exceptions overhead is comparable to that of an if statement?

I don't believe that EvoEx was saying that. Exceptions are for reporting an error in a manner that allows (or forces, depending on interpretation) error recovery in some code that may be completely unrelated to the code that detects and reports the error.

That involves some overhead, essentially based on control moving through a call stack from the throw point to the catch point. Implement the same thing using if statements, then it is necessary for all intervening functions to check the error condition, and to communicate information about the error. The overhead of such schemes depends on a lot of things. Sometimes it might be less than the overhead associated with exceptions. Sometimes it might be more.

Originally Posted by C_ntua

Is the statement then that try/catch is slow for compilers that use the modern version?

A more accurate statement is that the overhead of exception handling (be it performance, executable file size, or whatever) depends on compiler quality of implementation. Modern compilers are more likely to have better quality in this regard than older compilers.

It depends on your expectations though: some compilers (or optimisation settings) seek to optimise runtime speed. Others seek to optimise executable file size. There is rarely a setting that simultaneously optimises against one measure without being sub-optimal in another measure.

In practice the value, and acceptable overhead, of exceptions versus something else depend on the task at hand. In some "edge cases", a programmer might wish to use a different approach with a different compiler.

Just looking for statements of "exceptions are good" or "exceptions are bad" is foolish. People who want to be good programmers will decide between options, not slavishly follow over-simplistic rules.

I believe there is one more thing to elaborate on. Is exception handling really costly when no exception is thrown? Cause that is the common case. In comparison, the cost for checking the return code is fixed. You will pay it either an exception is handled or not. So it is more interesting comparing the cost of a return code in an if statement with a try/catch block when no exception is thrown

Originally Posted by C_ntua

Is exception handling really costly when no exception is thrown? Cause that is the common case.

It depends on the compiler but, practically, exception handling is not particularly expensive when no exception is thrown.

Apart from the throw and catch points (which aren't needed if no exception is thrown), the only other overhead of exception handling is with some form of "is there an active exception? If so ..." logic and maybe some memory for managing the thrown exception itself. The overhead of that - particularly as no more than one exception is allowed to be active at any time - is pretty small. And, if you know that no exception will be thrown, a lot of compilers have an option to eliminate support for even that.