6 ms·

I prefer Raymond Chen's take on exceptions: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx http://blogs.msdn.com/b/oldnewthing/archive/2005/

by McP 16y ago

I prefer Raymond Chen's take on exceptions: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...

Xurinos 16y ago
I didn't see any timings in his code.
- bediger 16y ago
  Yes. How can he possibly say that "exceptions are faster" without such timings? C++ style, unwind-the-stack-and-call-destructor exceptions must really have a high run-time cost when an exception occurs. Also, his instruction count misses the instructions that occur at run-time handling an exception. Even when an exception doesn't occur, it isn't obvious that some run-time code doesn't get excuted.
  - SoftwareMaven 16y ago
    But you have to unwind the stack either way. With exceptions, the exception handling does it. With error checking, you do it every time you type "if (something() == -1) return -1;"
bostonpete 16y ago
"since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it" Yes, that's my concern with exceptions as well. It seems like the Java model (if I remember it right -- it's been a decade), which requires a method to either handle an exception that a sub-method throws or explicitly allow it to be thrown, would be preferable and help people avoid accidentally ignoring an exception. I'd like to see support for exceptions like this in C++0X, but I haven't bothered to check to see if it's there...
- snprbob86 16y ago
  You're thinking of "checked exceptions" and C++ already has them (pre 0X) via the "throws" clause on method declarations. Checked exceptions is a hotly debatted topic and I think the world has kinda finally come around to deciding that the are a bad idea overall. Google it and see for yourself.
  - supersillyus 16y ago
    I don't know that it's accurate to compare C++ exception specifications with Java-style checked exceptions. Exception specifications aren't checked at compile time and typically don't do what you want at runtime.
    - snprbob86 16y ago
      shrug You're probably right. I've never really used them in C++, especially because I tend to avoid C++ in favor of the smallest possible amount of C to bootstrap primary use of a much higher level language.
  - cpeterso 16y ago
    As mentioned, C++ exception specifications are checked at run-time, not compile-time. And if your function's exception specification declares `throws(FooException)` and you call some third-party library function (which may or may not have its own exception specification!) that throws a `BarException`, C++'s runtime checks will `terminate()` your program! C++ exceptions and exception specifications are pretty much all the worst possible design decisions. :(
- SoftwareMaven 16y ago
  Requiring all exceptions to be checked is evil. It leads to horrendous abstraction leakage (I need to let every caller know I use FooBarWidget in the core of my application??), improper error handling (just catch whatever comes out and move on so I don't have to declare it), or ubiquitous error wrapping (every class has a try...catch that turns the called exceptions into new exception types to throw). Ironic that C++ is moving towards that as the Java community is moving away (by relying more on RuntimeException, which isn't checked).
AshleysBrain 16y ago
This reads to me like 'writing good code is hard, and writing even better code is even harder'. With modern C++0x smart pointers (like unique_ptr) and RAII, you can get very high performance and (more) easily exception-safe code. Maybe a lot of C++ exception criticism comes from people still trying to code like C in C++?
- marshray 16y ago
  Exactly.
- svlla 16y ago
  "modern C++" has changed meanings so many times in the past 10 years that it's not funny anymore. there's always some "modern" solution in C++ that ends up causing more problems, leading to further "modern" solutions that end up... you get my point. some folks have decided to get off the C++ feature treadmill and go back to, well... getting things done with solid languages (e.g. C) instead of learning about the latest C++ non-solutions to non-problems.
  - AshleysBrain 16y ago
    Hmm, well, I'm relatively young so I guess I missed all those broken promises :P Still, I think the "trying to code like C in C++" point still stands.
    - bad_user 16y ago
      Well, if you're ever bored, read this book: http://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315 http://www.amazon.com/Modern-Design-Generic-Programming-Patt...
    - jerf 16y ago
      A compressed version can be obtained simply by comparing the initial release of C++ to modern C++, and recalling that the initial version of C++ itself shipped with, well, pretty much the same set of promises that modern C++ ships with.

by McP 16y ago

I prefer Raymond Chen's take on exceptions: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...

Xurinos 16y ago

I didn't see any timings in his code.

bediger 16y ago
Yes. How can he possibly say that "exceptions are faster" without such timings? C++ style, unwind-the-stack-and-call-destructor exceptions must really have a high run-time cost when an exception occurs. Also, his instruction count misses the instructions that occur at run-time handling an exception. Even when an exception doesn't occur, it isn't obvious that some run-time code doesn't get excuted.
- SoftwareMaven 16y ago
  But you have to unwind the stack either way. With exceptions, the exception handling does it. With error checking, you do it every time you type "if (something() == -1) return -1;"

bostonpete 16y ago

"since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it" Yes, that's my concern with exceptions as well. It seems like the Java model (if I remember it right -- it's been a decade), which requires a method to either handle an exception that a sub-method throws or explicitly allow it to be thrown, would be preferable and help people avoid accidentally ignoring an exception. I'd like to see support for exceptions like this in C++0X, but I haven't bothered to check to see if it's there...

snprbob86 16y ago
You're thinking of "checked exceptions" and C++ already has them (pre 0X) via the "throws" clause on method declarations. Checked exceptions is a hotly debatted topic and I think the world has kinda finally come around to deciding that the are a bad idea overall. Google it and see for yourself.
- supersillyus 16y ago
  I don't know that it's accurate to compare C++ exception specifications with Java-style checked exceptions. Exception specifications aren't checked at compile time and typically don't do what you want at runtime.
  - snprbob86 16y ago
    shrug You're probably right. I've never really used them in C++, especially because I tend to avoid C++ in favor of the smallest possible amount of C to bootstrap primary use of a much higher level language.
- cpeterso 16y ago
  As mentioned, C++ exception specifications are checked at run-time, not compile-time. And if your function's exception specification declares `throws(FooException)` and you call some third-party library function (which may or may not have its own exception specification!) that throws a `BarException`, C++'s runtime checks will `terminate()` your program! C++ exceptions and exception specifications are pretty much all the worst possible design decisions. :(
SoftwareMaven 16y ago
Requiring all exceptions to be checked is evil. It leads to horrendous abstraction leakage (I need to let every caller know I use FooBarWidget in the core of my application??), improper error handling (just catch whatever comes out and move on so I don't have to declare it), or ubiquitous error wrapping (every class has a try...catch that turns the called exceptions into new exception types to throw). Ironic that C++ is moving towards that as the Java community is moving away (by relying more on RuntimeException, which isn't checked).

AshleysBrain 16y ago

This reads to me like 'writing good code is hard, and writing even better code is even harder'. With modern C++0x smart pointers (like unique_ptr) and RAII, you can get very high performance and (more) easily exception-safe code. Maybe a lot of C++ exception criticism comes from people still trying to code like C in C++?

marshray 16y ago
Exactly.
svlla 16y ago
"modern C++" has changed meanings so many times in the past 10 years that it's not funny anymore. there's always some "modern" solution in C++ that ends up causing more problems, leading to further "modern" solutions that end up... you get my point. some folks have decided to get off the C++ feature treadmill and go back to, well... getting things done with solid languages (e.g. C) instead of learning about the latest C++ non-solutions to non-problems.
- AshleysBrain 16y ago
  Hmm, well, I'm relatively young so I guess I missed all those broken promises :P Still, I think the "trying to code like C in C++" point still stands.
  - bad_user 16y ago
    Well, if you're ever bored, read this book: http://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315 http://www.amazon.com/Modern-Design-Generic-Programming-Patt...
  - jerf 16y ago
    A compressed version can be obtained simply by comparing the initial release of C++ to modern C++, and recalling that the initial version of C++ itself shipped with, well, pretty much the same set of promises that modern C++ ships with.