C++ - The Forgotten Trojan Horse

Later I was able to get my program to compile on Visual C++ with absolutely no modification.

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.

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