Those aren't his thoughts. Those are his thoughts morphed into a flame meant to stop people from bugging him about a particular decision he made that he believed was correct and didn't want to revisit ad nauseam.
> the whole C++ exception handling thing is fundamentally broken
While I completely agree that using C++ in the kernel is not the brightest idea, I am curious what's so fundamentally broken about C++ exception handling. It certainly comes with performance penalties, sometimes considerable (especially on the fast paths), but why is it flawed fundamentally ?
One thing that I consider fundamentally broken is throw-lists: if a C++ function ever throws an exception that is not in its throw-list, the program terminates. (The only way to avoid this is to omit the throw-list entirely, so I always omit it.)
There are of course a few things wrong with this design.
One is that even deeply nested exceptions count; so if you've vetted your code and listed every exception that you throw, you're still screwed if you call a function that eventually throws something else.
This of course leads to the next problem: code evolves. Suppose you did somehow review all possible code that your function will touch, and wrote an accurate throw-list. Then next week, Jim goes into one of those buried routines and makes it throw something new; boom, you are once again at risk of terminating.
Yet another problem: suppose the messed-up throw list is in a library. Not only does this mean a library is responsible for exiting your program at a completely inappropriate point, but it might be a library that you can't easily change. So you're forced to declare implementation-specific exceptions that have no meaning to your callers. (Or just don't declare, as I do.)
The real issue of course is that terminating is a stupid behavior, even though they define terminate() to give you a point of interception. There are all kinds of reasons why you might accidentally mess up a throw-list, and since all you really gain for "fixing" this is a little code purity, it hardly seems worth dealing with severe runtime errors.
Almost makes sense to me, except any feature in C and C++ can be criticized this way. In the C/C++ land you have access to hardware, plus almost every resource (except maybe function stack frames) is allocated and deallocated manually. In C/C++ you can make a mistake with virtually any operation that involves pointers, buffer overruns being perhaps the most popular one. So? Dump pointers altogether?
Or take "return" - basically same problem as with "throw" (although only within one function) - it can bypass some resource deallocations.
C/C++ is like a scalpel, it requires professionalism and great, great care and you can do wonderful, magical things with it.
I'm not sure about fundamentally broken, but back when I was deeply entrenched in C++ it was clear that it is diabolically hard to write C++ code that behaves correctly in the face of all the places and times exceptions may be thrown.
There are zillions of corner cases - things like handling of exceptions thrown from destructors (remember, destructors get called implicitly as C++ unwinds the stack, possibly due to ... another exception) that get so complex and weird it is barely possible to understand, let alone correctly code for them.
I'm sure if he shared his actual thoughts, it would bring him some serious hassle, what with people wanting to debate with him. Much easier just to make it clear he isn't willing to be reasonable on the topic.
