Hacker News Reader

Comment by bostonpete | Hacker News Reader

"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...

View on HN

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.

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.

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.

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. :(

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).

> It leads to horrendous abstraction leakage (I need to let every caller know I use FooBarWidget in the core of my application??),

If your code catches any exceptions that might be thrown by its use of FooBarWidget, then you wouldn't need to specify it as an exception that your code might throw, right? If it doesn't, then your code exposes to callers that it uses FooBarWidget every time FooBarWidget throws an exception.

Reply on news.ycombinator.com