exceptional exceptions in C++

For  a long long time I have read about exceptions, programmed them and also seen how horribly they go wrong. I know and understand that exceptions are not supposed to be an after thought but supposed to be designed along side the classes. Nice and good. However I hate the fact that an exception raised in line 10 gets caught all the way down 100 lines. That sounds eerily similar to the goto statement. It just means that now I have to touch two sections everytime I allocate resources. That’s not my style of writing. It is also one of the many reasons why I use templates. Having written code in a bunch of programming languages, I’ve come to conclude that the lesser the code that we write the fewer the bugs we encounter. The fewer the number of things that a programmer should modify to achieve a goal the fewer the number of  memory leaks and resource leaks. After all how many people have written buggy “hello world” programmes?

Exceptions seem to demand that I write the same statement twice (especially with memory). One possible way to fix this is the shared pointer, auto ptr and a bunch of other constructs that turn pointers into stack elements. Then there is the issue with exceptions sucking up a lot of processor time. The last time I check (won’t mention the platform or the compiler – NDA) I noticed a 15% drop in frame rates. I haven’t used it since and I am unaware of how much better (if at all) the compilers have become.

Then there is the issue with the depth of the exceptions. Everytime I add a new node to the exceptions hierarchy, I seem to miss the fact that the parent will catch the exception if it is listed before the child in the catch block.

Hence I generally go back to returning error codes, especially when I am writing games. Hey, it is afterall just an enum that I declare there, right?

Stupid stupid stupid OGL mistake

Spent like a whole day on a silly little display lists bug. So what happened was that I was building/compiling a display list in the constructor of my renderer class. It just turns out that this is not the best way of doing things. When I called to render the display list it kept throwing a “GL_INVALID_VALUE” error. Fixed this when I moved constructing the display list into the initialisation function. Hoooray. Now to find out why this actually happened. What’s special about the constructor of a C++ for the OGL api. Logic tells me that there is something I am missing here. Does the internet(s) have an answer?
BTW I got a crash when I was building mipmaps using gluBuild2DMipmaps inside the constructor.