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