[Quarrelsome]

Nice article but as far as I'm concerned you don't need to _prove_ this as it is a logical fallacy to start with.

If an exception is being thrown then something is wrong, if something isn't wrong then you implemented your exceptions incorrectly as exceptions shouldn't exist in normal program flow.

So to recap, you're writing a crap ton of more code just so you can return your error code _slightly_ faster than it would take an exception. You're optimising your failure cases, which (in the _vast_ majority of cases) is UTTERLY ABSURD.

[shin_lao]

It's not slightly faster, it can be an order of magnitude faster.

Example: a listen loop which handles disconnections through exceptions. This isn't stupid but it's not very efficient.

[Quarrelsome]

Why is it not stupid? If disconnections are part of normal application flow then why would you use an exception?

You are correct, I was somewhat disingenuous with _slightly_ faster. It is lots faster but lots faster in error cases, which from a philosophical angle is still absurd.

As long as you use your exceptions for "bad shit" (uncommon error conditions or completely unexpected failures or returns) then I still strongly believe that the performance comparison is silly.

[anonymous246]

Maybe I'm missing something. Are you saying that in your application, handling rarely-occuring unanticipated disconnections via exceptions has such high overhead that its results in unacceptable performance?

[aplusbi]

I think you partially missed the point - it's not that throwing exceptions is slow, is that even having them in your code is [allegedly] slow.

According to the article there are two methods used to implement exceptions in C++ - one that has higher overhead when you throw an exception (zero-cost) and one that has higher overhead when you call a function that might throw an exception (setjmp/longjmp).

Unfortunately the author didn't go over the latter method, which would have been more interesting.