Skip to main content
gamedev.net
🔒 Locked

Call Stack Dump + Exceptions Question.

Started by HexDump Feb 26, 2003 at 11:39 AM 2 replies 300+ views
Original Post
HexDump
HexDump
Hello everybody, I have been reading about exceptions, pretty simple stuff (or they seem to be at first). The thing is that they have not convince me. I think I will keep going with the old skool error checking method (if/else) . My first attempt was to use them in order to catch bad calls in my code and dump the call stack (very handy I think), but now that I have decided not to use them I need a method to dump this call stack in an easy way. A dumb question... could I dump the Method names instead of their adresses? Is there any built In symbol (like __LINE__, etc...) that gives me this info?. Well that''s all, sorry for my poor english, I´m spanish and I´m in a hurry . Note: I don´t mind if anyone wants to convince me about using Exceptions, if he/she gives me good reasons to do it. The main problem I found with execptions is that they do the same we did before but in a new fashion, and this is not enough for me. I´m using vc6.0 + dx9 HexDump.
fizban75
fizban75
Here''s one example of why excpeptions are necessary and sometimes preferred:

In my code, I hardly ever create classes that have "init()" routines. In my opinion, that''s a cause for error for a programmer using my libraries (including me!). So, I follow the idiom of "instantiation is initialization" which means that all initialization of the members in my class is done during the construction of the class.

Now, if something goes wrong during the initialization, I sure can''t return an error code from the constructor, so I throw exceptions instead. If the failure of the construction of a class is okay, then I catch the exceptions and continue. If it''s a big failure that can''t be managed, the exception propagates out until someone else catches it or the program terminates.

I actually believe that exceptions, when used properly, make for robust code. They force fatal errors to be managed, where as a return code for a fatal error could be ignored causing the program to be harder to diagnose when it possibly crashes later on because of the ignored return code.

However, I don''t use just exceptions. There are times and places for both exceptions and return codes, and a good programmer knows when to use one and not the other.

Shannon Barber
Shannon Barber
The C++ exception model is brain-dead. While there are lots of useful things an exception handling framework could do (like *TRACE THE STACK*) The C++ one doesn''t do jack. While other systems usually offer more functionality they are lacking as well. A good thing to have is a failure to compile if the exception gaurantees are not met. Some systems will automatically build a call-chain, which is nice but only half the job.

If you want your exception handling routines to do something useful, you need to use the platform specific API. You can actually save the state of a crashed program and debug it at your leisure on your development machine. In kernel land, they call these core dumps.
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.